An exchange and its design
A failed handover request may need a retry or an investigation. If staff repeatedly cannot establish what happened, the interface may need a way to look up each operation’s result. Retrying a request follows the agreed design; adding result lookup changes it.
Process areas
Visioning, Transforming, Operating and Governing are the continuing process areas in A Simple Architectural Framework (ASAF). They can overlap within a service review or delivery increment. A cycle may revisit one question or connect several areas; its scope and trigger determine who needs to take part.
| ASAF process area | Work and decision | What can reopen it? | Retained information |
|---|---|---|---|
| Visioning | Agree the service responsibilities and qualities the solution should provide. | A new need or failed assumption changes the intended solution. | System context, core meanings, alternatives and responsibilities. |
| Transforming | Design and implement contracts, rules and components; check compatible transition. | A failed interaction or implementation check reopens an affected decision. | Contract and implementation versions, checks, migration and recovery plans. |
| Operating | Resolve failed exchanges, maintain service behaviour and investigate recurring faults. | An unknown result, reconciliation gap or support problem requires action. | Operation history, incidents, version context and proposed corrections. |
| Governing | Agree authority, shared contracts, acceptance conditions and exceptions. | A change affects business meaning, another team or an accepted risk. | Decision rights, accepted contracts, reasons and unresolved conditions. |
Retain decisions that still hold. A changed phone interface may require new offline behaviour without changing what learner agreement means. A supplier that cannot confirm a booking may require a wider process decision.
Behaviour within the system
Detailed design, implementation and support can have their own feedback loops within these process areas. A small iteration may cover all three questions below.
If a check finds that an offer can be accepted after the agreement has changed, the team may need to correct a version check, clarify the offer’s meaning, or both. The decision belongs with the responsibility it changes.
| Question within a change | Work and decision | Retained information |
|---|---|---|
| Behaviour and design | Agree rules, component responsibilities, state and failure results. | Examples, invariants, contracts, alternatives and reasons. |
| Implementation and checking | Change code, prompts and adapters; check the agreed behaviour. | Versioned changes, checks, actual results and unresolved defects. |
| Operation and learning | Investigate incorrect or slow behaviour and propose a correction. | Input and version context, failures, support effort and affected cases. |
An implementation defect can return to a focused change. Ambiguous business meaning returns to the service owner and the relevant information or process record. Retain correct parts of the design between iterations.
Change across participants
Before changing an interface, identify consumers, supported versions and how each will move. An added optional field may be easy to tolerate; a changed meaning for “accepted” can break a process without changing the message shape. Use old and new examples to check both structure and behaviour.
Recovery also needs a design. Reverting code may not undo a booking, a sent notification or an accepted transfer. Record which facts remain valid, which corrections are needed and who can approve them. The change record provides a starting point.
Learning from use
Observe how long it takes to identify an unknown result, clear failed work and bring a new consumer into service. Link incidents to the contract version and actual case history. Repeated manual reconciliation may justify an interface change; a single invalid request may need only a local correction.
Retaining the baseline
Keep the accepted rule and examples alongside the implementation version. When an artificial intelligence (AI) assistant helps draft a change, give it those contracts and the specific intended difference. Review the result against them rather than reconstructing the whole solution in each turn.
For a proposed model step, retain the inputs, prompt/schema versions, relevant provider configuration and evaluation cases. Repeated trials examine variation; a single convincing result is not a dependable baseline. A prompt correction must preserve the validator’s intended meaning.
Returning a finding
The worked example separates a transfer plan from the operation that saves it. A check showing two accepted assignments would reopen concurrency control. A summary that invents learner agreement would reopen its generation or validation path; it would not grant the model authority to accept the agreement.
Methodology configuration
Map these decisions to the architecture, design, implementation, release and service reviews in your method. One iteration may contain several activities. Retain the agreed contract while local changes are made, and return questions about business meaning to its owner. The configuration guidance and Systems records help connect the decisions.
Dials
The arrangements and questions below apply the six shared dials: cadence, batch size, coordination, decision authority, automation and checking, and learning reach.
| Arrangement | How the cycles fit together | Control to keep |
|---|---|---|
| One major release | Most contracts are agreed before integration and service acceptance. | Reopen assumptions when participant behaviour or trial results differ. |
| Incremental delivery | Establish core responsibilities, then add operations or consumers in stages. | Track dependencies and support the versions present during transition. |
| Agile delivery | Revisit detailed contracts within short delivery cycles. | Keep shared meaning and changes visible to teams that release separately. |
| AI-assisted delivery | Tools may draft contracts, adapters and checks more quickly. | Review their meaning, permissions and failure behaviour; retain decisions and test results. |
These are illustrative arrangements. A team may combine them, or place several cycle concerns within one review or iteration.
A staged project may settle major component contracts before implementation. An incremental approach may develop one rule and its supporting path at a time. Short iterations can revisit both, with the scope of a review determined by the change’s effects.
| Concern | Question |
|---|---|
| Scope | Is this a local calculation, a shared rule or a change to accepted business meaning? |
| Coordination | Which callers, maintainers and data owners must understand the change? |
| Automation | What can tools generate or check, and what still needs a decision? |
| Feedback | Which fast checks expose mistakes, and which failures require the real storage or service? |
| Release | Can old and new code, contracts and pending work coexist during transition? |