ZAF dossier — continuous edition

01 · Executive purpose and institutional promise

1.1 What this dossier is for

An architecture dossier must help leaders decide what the organization is building, which responsibilities it must retain and what evidence would justify investment. A list of technologies cannot answer those questions. ZAF connects purpose, capabilities, operating constraints and engineering decisions in a record that can be challenged and revised. This public edition is a reference method with a fictional institutional example. It is not a client blueprint, a certification, an implementation claim or a substitute for the institution’s authority. The example is a regional service institution with a headquarters, six offices and an assumed two-person engineering team. Its first scope is operational requests and consolidated reporting; payments, national identity and nationwide deployment are excluded.

1.2 The promise to protect

For the selected workflow, an accepted request must have an identifiable origin, an authorized decision, a traceable version and a recoverable outcome. “Accepted” means acknowledged by the authoritative service, not merely stored on a disconnected device. The promise remains meaningful if the technology changes. A request may be delayed or rejected for a stated reason. It must not silently become two requests after a retry, inherit approval for changed content or vanish between application and reporting. These are candidate invariants for stakeholder approval, not properties already demonstrated by this example.

1.3 Executive assessment

The fictional organization can launch separate applications but cannot yet show consistent approval ownership, reporting definitions or a demonstrated restore. The strategic gap is the ability to repeat a trustworthy service across offices. The recommendation is to establish one authoritative journey and common supporting capabilities before multiplying services.

1.4 Reading the architecture as a city

Domains resemble buildings with different purposes. Shared identity, integration, delivery and observability resemble civic services. Governance defines the rules for using them; the platform team operates agreed common capabilities. This analogy explains responsibility and reuse. It does not mean every capability needs a separate service, database or team.

1.5 Required executive record

• A signed purpose statement and explicit exclusions.
• The institutional promise and measurable candidate acceptance scenarios.
• Named business, data, system and risk owners.
• A record of assumptions, unresolved decisions and authorized next work.

1.6 Decision gate

Proceed to discovery when the sponsor accepts the first journey and assigns accountable owners. Do not approve a technology procurement solely because the target diagram looks complete. The first management decision is scope and authority; detailed component selection follows evidence.

02 · Institutional context and business capabilities

2.1 Begin with a decision, not an application inventory

The institution needs to authorize operational work, execute the approved action and explain its reporting. An application is one possible means. The capability model describes what must be possible even when offices, software or suppliers change. It should be stable enough to guide ownership without becoming a permanent organizational chart. For the worked example, discovery follows one request from submission to departmental review, finance approval, fulfilment and reconciliation. Rejected, withdrawn and amended requests are part of the journey. Describing only the successful path hides the decisions that often create operational risk.

2.2 Stakeholders and authority

A role name does not establish its legal or organizational authority. Interviews must distinguish policy, delegated authority and actual system permissions. A supplier must not invent a delegation rule because it simplifies the workflow.

2.3 Capability and responsibility map

2.4 Local operating constraints

Connectivity, power, language, device sharing and maintenance access must be investigated at each selected office. “Low bandwidth” is too vague to design against. Capture representative conditions, the longest tolerable interruption and which tasks remain possible during it. For the scenario, disconnected drafting is proposed while final approvals remain online. This is a continuity policy with a cost: an office may have to wait. The business owner must compare that delay with the consequences of conflicting approvals. Offline finalization is a separate decision requiring conflict resolution and delegation rules.

2.5 Deliverables and acceptance

The context chapter produces a stakeholder register, one end-to-end journey, a capability map and a constraint register. Validate them in a joint walkthrough with the people who request, approve, fulfil and reconcile work. Record disagreements as open decisions with an owner and a due point. Acceptance means the map describes the agreed responsibilities; it does not mean a production system has been proven.

03 · Current-state assessment and evidence register

3.1 Separate observation, testimony and assumption

A useful current-state chapter explains how a finding was obtained. “Users say reporting is unreliable” is testimony. A sampled report that cannot be reconciled is an observation. An expectation that every branch has the same problem is an assumption. All three can guide discovery, but they have different evidential weight. The fictional baseline contains spreadsheets, email approvals, a legacy application and manual exports. No investigation of a real institution is implied. Candidate sample sizes and test windows must be agreed according to access, risk and the diversity of journeys rather than presented as a statistically representative audit.

3.2 Assess one complete transaction

Select a permitted sample of completed, rejected and changed requests. Reconstruct the submitted content, actor authority, approval version, fulfilment record and reporting inclusion. Note where the chain becomes uncertain. Capture minimal evidence with redaction and an agreed retention rule; copying an entire production database is not a default discovery activity.

3.3 Examine the system as operated

Map authentication, data stores, integrations, scheduled jobs, release procedure, backup locations and support responsibility. Include manual workarounds. A spreadsheet emailed after a failed export is part of the operating system even if it is absent from the software diagram. Evaluate access with positive and negative tests appropriate to the authorized scope. Review how configuration is changed, who can access secrets and whether a departed user can still act. Do not execute disruptive tests or extract sensitive records without an agreed test boundary.

3.4 Baselines before targets

A baseline describes the sample and its limitations. Do not convert a small demonstration into an institution-wide percentage. The output is a defensible starting point for decisions, not a maturity score designed to make the proposed solution look necessary.

3.5 Assessment package

Publish a redacted system inventory, journey trace, evidence register and open-question list to authorized stakeholders. Each finding references evidence or an explicit assumption. The system owner confirms factual accuracy; the architect remains responsible for the interpretation and recommendation. Unresolved disagreements remain visible in the decision record.

04 · Gap analysis and risk prioritization

4.1 A gap is relative to an agreed outcome

A missing tool is not automatically a gap. If the institution cannot establish that execution matches the authorized request, the gap is decision integrity. A workflow engine might help implement a remedy, but naming one does not establish the problem or its priority. For every gap, connect the current evidence to the institutional promise, describe a plausible failure and identify an accountable risk owner. Distinguish a weakness from a realized incident. “Could allow an unauthorized change” and “has caused unauthorized changes” are different claims.

4.2 Prioritize consequences and uncertainty

P1 and P2 are ordering labels for this constructed example. They are not a calibrated institutional risk rating. Actual likelihood, financial impact and legal consequence need local evidence and authorized interpretation.

4.3 Follow the dependency chain

Fixing reporting before agreeing the authoritative approval state may encode an unstable definition. Replicating an unrecoverable system to more offices increases exposure. The sequence therefore begins with authority and recovery requirements, then validates one journey, then expands coverage. A high-risk unknown can justify discovery before implementation. For example, data placement may change the feasible hosting design; branch continuity requirements may change the consistency model. Record the decision blocked by each unknown and what evidence would release it.

4.4 Remediation options

For G-01, compare retaining the current application with a controlled versioned approval extension against replacing the workflow completely. The narrower extension may reduce migration risk if the existing system can support the required invariants. Replacement becomes more plausible when ownership, testing or integration constraints make that extension unsafe. For G-02, a backup product purchase alone is insufficient. The remedy includes protected backup access, a known recovery point, an isolated restoration procedure and a responsible person able to demonstrate it. The institution must accept residual risks such as recovery delay and manual reconciliation.

4.5 Risk acceptance and closure

• Record the finding, evidence reference, consequence and owner.
• Compare feasible treatment options and their operating costs.
• Define an observable closure test and the evidence to retain.
• Record residual risk, exception authority and the next review trigger.

A gap is closed when the agreed evidence supports closure, not when a ticket is marked done. The architect recommends treatment; the authorized institutional owner accepts residual risk.

05 · Architecture principles and quality scenarios

5.1 Principles must constrain a real decision

“Secure, scalable and modern” does not help resolve a conflict. A principle should state a rule, its rationale, the decisions it changes and the procedure for an exception. It should survive replacement of a framework, database or supplier. For the example, approval authority, traceable information and recoverable operation take precedence over adding distributed components. That does not prohibit distribution. It requires a reason and the operating capacity to support it.

5.2 Turn qualities into scenarios

A quality scenario identifies the actor, stimulus, operating condition, expected response and measure. “Fast approval” should distinguish software response from the human approval interval. Improving API latency cannot solve a policy queue awaiting an absent approver.

The numbers above are design assumptions for the fictional case. They become commitments only after impact analysis, cost discussion and demonstrated feasibility.

5.3 Security and continuity can conflict

Requiring online authority preserves consistency but may interrupt a branch during a network failure. Allowing offline approvals may preserve local activity while creating conflicts the institution cannot resolve. Document that tension explicitly. A cache is a technical mechanism; the authority policy is a business decision. Similarly, keeping all data forever can aid investigation while violating retention requirements. Choose the minimum evidence needed for the approved purpose, with controlled access and an authorized retention rule.

5.4 Principle review

The architecture review records where a principle was applied, where it conflicts with another objective and who approves an exception. Review exceptions when their trigger occurs rather than letting temporary workarounds silently become permanent standards. The chapter is accepted when stakeholders can use the principles to explain a selected option and reject an unsuitable one. If every possible solution “complies,” the principles are not specific enough.

06 · Business domains and shared platform capabilities

6.1 Separate what changes for different reasons

A business domain owns the meaning and rules of its work. A shared platform capability provides a repeatable service used by several domains. Technology implements either responsibility. Infrastructure hosts the implementation. Keeping those categories distinct prevents the architecture from becoming an inventory organized around product names. In the fictional institution, request management owns request versions and transitions. Fulfilment owns execution facts. Finance owns reconciliation and reporting definitions. Shared identity establishes authenticated actors; it does not decide whether a particular actor may approve a particular request. That authorization remains connected to the domain policy.

6.2 Responsibility boundaries

6.3 Share capabilities without creating a bottleneck

Shared does not mean centrally approving every small change. Define a service contract: what the capability provides, who operates it, how consumers gain access and what changes require coordination. A notification capability accepts a delivery intention; it must not become the authority for whether the originating decision was valid. For a small team, these responsibilities can exist as modules and assigned duties within one deployment. The diagram does not mandate six independent services. Separate deployment requires evidence of a need such as independent ownership, isolation or release cadence, together with a support model.

6.4 Federation needs enforceable agreements

Common rules cover identity claims, audit identifiers, contract compatibility and operational handover. Domain owners retain specific policy decisions within those rules. Exceptions require an owner and review trigger. A central architecture function should resolve cross-domain conflicts without taking over every domain’s implementation choices. When two modules need the same fact, name its authority. A report may retain a projection of an approval, but it must identify the authoritative version and freshness. Directly editing that projection to “fix the number” would bypass the owner and break traceability.

6.5 Required artifacts

• Domain boundary map with authoritative facts and owners.
• Shared capability catalog with consumer and support contracts.
• Cross-boundary dependencies and compatibility expectations.
• Rules for ownership disputes, exceptions and decomposition.

The review gate is a walkthrough of an amendment crossing request, fulfilment and finance boundaries. If each owner can explain what changes, what remains stable and how a conflict is resolved, the model is useful enough to guide design.

07 · Target architecture and end-to-end behaviour

7.1 Recommendation and rationale

The proposed first target is a modular application with an authoritative relational store and recoverable background work. This is a scenario-specific response to limited operating capacity and a need for transactional integrity. It is not a statement that a modular application is suitable for every institutional platform. The target keeps workflow transitions, permission decisions and request versions close to their authoritative data. Reporting and notification delivery are separated logically because they can tolerate delay and have different failure behaviour. That separation can be implemented within a controlled deployment before introducing independently operated services.

7.2 Logical architecture

The browser sends an authenticated command with an expected version and stable command identity. The API derives the actor from authenticated context, checks organizational scope and validates the transition. A transaction records the new state, audit entry, command result and any outbox intention. The worker processes committed background work. A notification failure must not undo an accepted approval. The report projection identifies its source and processing cut-off. Attachment storage, identity provider and backup destination remain separate controlled boundaries even when omitted from a simplified drawing.

7.3 Successful journey and rejected journey

Do not conflate a rejected command with a failed service. A forbidden approval may be correct system behaviour. Telemetry and support procedures must distinguish business rejection, technical failure and an outcome the client cannot yet determine.

7.4 Concurrency and recovery boundary

A read followed by an unconditional update is not sufficient to protect an approval version. Select a conditional update or locking strategy and test competing sessions. Scope command keys, compare repeated payloads and decide their retention. Transaction isolation is a mechanism to choose deliberately, not a label guaranteeing every invariant. The architectural acceptance includes a lost response after commit, a concurrent edit before approval and a stopped worker. Each scenario must leave the authoritative state explainable. The exact implementation belongs to the design package and code review; this dossier does not claim that the example has been built.

7.5 Target review outputs

Produce a context diagram, logical view, state-transition definition, trust boundaries and failure scenarios. Link each target element to a requirement or gap. If a component has no responsibility, requirement or operational owner, remove it or explain why it is needed.

08 · Data architecture, ownership and trustworthy reporting

8.1 Assign authority before designing a warehouse

The institution needs an agreed meaning for request, approval, fulfilment and outstanding obligation. A database schema can encode a definition; it cannot establish its institutional authority. Name the owner who decides the meaning, the steward who investigates exceptions and the technical custodian who operates storage. For the example, a request version is authoritative in the request domain. Execution facts belong to operations. The finance report combines those facts under an approved contract without rewriting their source meaning.

8.2 Information model

Retention and access apply to these objects and their copies. The design must identify sensitive fields, attachment handling and any permitted use in test environments. “Keep raw data” is not a blanket permission to retain everything indefinitely.

8.3 Source-to-report lineage

Separate business event time, arrival time and publication time. A branch may submit Monday’s execution after reconnecting on Wednesday. Replacing the business timestamp with ingestion time would change the report’s meaning. Record corrections as revisions or authorized adjustments according to the institution’s policy.

8.4 Reporting contract and quality controls

Define grain, included states, period, currency treatment, expected sources and late-arrival policy. For one known cut-off, reconcile eligible source records against accepted records and identified exceptions, where those sets are mutually exclusive by definition.

• Missing references remain visible with a responsible steward.
• Repeated input does not duplicate an accepted fact.
• Corrections have a version policy and a replay test.
• Publication states whether expected sources are complete.
• A successful processing job does not by itself establish correct totals.

8.5 Analytical evolution and AI readiness

A daily projection is proposed initially because the scenario has not established a real-time decision need. Introduce a separate analytical platform when history, isolation or analytical workload justifies the additional operating contract. AI use requires a separate problem definition, permitted data use, evaluation set, error consequences and human oversight. A clean data pipeline does not prove a model is appropriate. Begin with traceable data and a measurable decision problem; do not label ordinary reporting as AI to make the architecture appear more advanced.

8.6 Acceptance package

The data owner approves definitions and retention. Finance signs off a representative reconciliation. Engineering demonstrates replay and correction behaviour. The architecture record links source objects to report fields and exposes unresolved quality limitations before the report is relied upon.

09 · Integration, APIs and event contracts

9.1 Distinguish a command from a fact

A command asks an authority to decide or perform an action. An event describes a fact that has already occurred under a named authority. An API can carry either interaction; a broker does not turn an invalid fact into a valid one. In the worked example, ApproveRequest is a command directed to the request boundary. RequestApproved is a fact emitted only after a valid transition commits. A notification service may consume the fact but cannot change what was approved.

9.2 Contract fields and semantics

9.3 Commit and delivery sequence

Record the state change and outbox intention within one transaction. A worker claims committed work, delivers it and records progress. If delivery succeeds but acknowledgement is lost, processing may repeat. Consumers therefore require deduplication or idempotent effects; the outbox is not an end-to-end exactly-once guarantee. Ordering should be specified per business object when later facts depend on earlier ones. A global ordering requirement can impose unnecessary coordination. Decide how a consumer detects a missing predecessor, retries processing and exposes work that cannot proceed.

9.4 Compatibility and partner onboarding

Changing a field name is not the only breaking change. Reinterpreting “approved amount,” changing currency meaning or omitting an event for a previously included state can break a consumer without changing the schema shape. Maintain contract owner, version, example payloads, error catalogue and deprecation policy. Before a new integration is enabled, verify identity, permitted data, rate behaviour, timeout handling, replay behaviour and a named support route. Do not treat possession of an API key as agreement on business responsibility.

9.5 Verification matrix

• Repeat the same command after an ambiguous timeout.
• Change the payload while reusing its key and verify a defined refusal.
• Deliver an event twice and verify one intended business effect.
• Process a compatible old payload and reject an unsupported version clearly.
• Interrupt the worker and recover pending work without losing its trace.

The output is a contract catalogue and testable interaction design. A broker or gateway purchase follows only when its capability is required and operated.

10 · Security, trust boundaries and data sovereignty

10.1 Security is a responsibility model

Authentication proves a presented identity according to a mechanism. Authorization decides what that actor may do to a particular object in a particular context. Encryption protects selected communication or storage boundaries. None of these mechanisms alone establishes institutional trust. The example requires explicit boundaries between users, application services, administrators, storage and recovery copies. A locally hosted system can still expose data through logs, telemetry, support exports or backup destinations. Data sovereignty therefore needs an information-flow and responsibility assessment, not only a server-location statement.

10.2 Trust and information boundaries

10.3 Threat-informed design

For a request approval, consider identity misuse, cross-department action, replay, changed content and unauthorized evidence alteration. Identify the asset, actor, entry point and plausible consequence. Prioritize controls against the agreed scenario rather than claiming coverage of every possible threat. A detailed threat review must include account recovery, service credentials, administrative access, audit access and incident response. Do not store raw credentials or sensitive personal records in application logs. Redaction, retention and access review belong in the operating design.

10.4 Sovereignty and supplier responsibility

The data owner approves classification, permitted locations and uses. Legal or policy authority determines applicable obligations; the architect records the requirement and its design consequence. The supplier provides evidence that the agreed boundaries are implemented and identifies subprocessors or external destinations where relevant. A claim of “fully local” is not accepted until backups, identity services, email, monitoring, developer access and support paths are examined. Conversely, local hosting is not by itself a security guarantee. Capacity to patch, monitor and recover matters.

10.5 Security acceptance

The design package contains a trust-boundary view, access matrix, secrets lifecycle, retention decisions, incident escalation and a test scope. Acceptance requires permitted and forbidden journeys, evidence of access removal and a protected recovery exercise. Unresolved risks have named owners and explicit treatment decisions.

11 · Infrastructure, delivery and service continuity

11.1 Define the operating envelope

Infrastructure selection begins with approved data placement, workload, availability, recovery and support constraints. For the fictional institution, local control is a candidate requirement to validate, not a claim about an existing installation. A deployment diagram must distinguish logical roles from independent physical failure domains. Two containers on one host do not provide host resilience. Replication is not a backup. An untested disaster-recovery diagram is an intention, not a demonstrated capability. Each claim requires a failure model and an exercise.

11.2 Candidate deployment view

This conceptual view separates access, application processing, authoritative storage and protected recovery copies. It deliberately does not prescribe a highly available cluster for a team that has not established its operating capacity. The final design must choose host count, power, network, storage and recovery locations against approved objectives.

11.3 Recovery objectives and cost

A candidate objective becomes a commitment only when scope, exclusions, dependencies, staffing and cost are approved. Record which functions return first and which manual reconciliation is required after restoration.

11.4 Release engineering

Every release identifies source revision, artifact, configuration, schema change and verification result. Required checks follow the risk. A schema change may require compatibility tests and a staged migration; an access change needs negative authorization tests. The recovery plan distinguishes application rollback, forward repair and data restoration. Reusing a previous container image does not undo a destructive data change. The release owner must know which strategy is permitted before deployment.

11.5 Continuity exercise

Simulate a defined failure in an authorized isolated environment. Record detection, decision, restoration, reconciliation and return to service. Compare actual results with the approved objectives and record corrective work. An exercise that omits attachments or required keys cannot establish complete recovery.

11.6 Acceptance package

Deliver the deployment view, failure-domain inventory, release procedure, protected backup policy and restore runbook. The system owner accepts operating responsibility; the sponsor accepts the residual continuity cost and risk. Infrastructure complexity expands only when its benefit and ownership are explicit.

12 · Governance, platform ownership and operating model

12.1 Architecture needs a decision system

A diagram cannot assign authority by itself. Governance identifies who decides, who supplies evidence, who operates the outcome and who may approve an exception. The operating model must fit the institution’s people rather than reproducing the structure of a much larger technology company. In the fictional two-engineer team, several roles may be held by the same person. The responsibilities must still be distinguishable, and critical approvals need an appropriate independent check. A separate platform capability does not automatically require a separate department.

12.2 Responsibility matrix

Accountability is not transferred to a software vendor by leaving a cell blank. The service contract should explain which responsibilities are delegated and which the institution retains.

12.3 Architecture decision lifecycle

A decision record includes context, evidence, constraints, options, recommendation, consequences and a review trigger. Proposed, accepted, superseded and withdrawn states should be explicit. Retain the rationale when replacing a decision so future teams understand why the earlier choice was reasonable. A lightweight review may be enough for a local module change. A cross-domain contract or sensitive data destination requires broader review. Classify changes by consequence rather than demanding the same committee for every commit.

12.4 Run the service after handover

Define service hours, support route, escalation, access review, patching, backup exercises and exception ownership. Incident response must include business communication and reconciliation of uncertain outcomes, not only restarting the process. Record operational knowledge where the team can use it. A runbook should name prerequisites, permissions, actions, verification and escalation. Test it with someone other than its author where possible. Personal availability is not a durable support model.

12.5 Governance outputs

• Role and decision-rights register.
• Service catalog with operating and consumer contracts.
• Architecture records and time-bounded exceptions.
• Incident, release and recovery responsibilities.
• Periodic evidence review and improvement backlog.

The acceptance gate is a scenario walkthrough: a failed release, uncertain approval or overdue reporting job must have a decision-maker and a response. Governance is effective when that route works, not when the organizational diagram looks complete.

13 · Technology mapping, economics and decision records

13.1 Choose an implementation for a capability

Technology is evaluated after the required capability and operating contract are known. Compare options against functional fit, team competence, security, data placement, lifecycle, recovery, integration and exit cost. A familiar product can be a reasonable choice; familiarity alone does not establish its suitability. For the scenario, the recommendation is a modular backend, PostgreSQL and a recoverable background worker. Specific language and hosting remain subject to maintainers, approved placement and test evidence. Kafka, Kubernetes and a separate warehouse are not initial requirements simply because the long-term vision is ambitious.

13.2 Technology mapping

13.3 Decision records

These are reference recommendations, not accepted decisions by a real institution. An actual decision record names its approver, date, evidence and conditions.

13.4 Evaluate total operating cost

Compare discovery, implementation, migration, licenses where applicable, hosting, connectivity, staffing, support, recovery exercises and eventual exit. A free license does not make operation free. A managed service may reduce some work while adding cost, dependency and data-placement questions. Do not publish invented savings or precise infrastructure prices for an unmeasured scenario. Build cost ranges with explicit assumptions and sensitivity to workload, retention and service hours. Separate one-time change cost from recurring service cost and the institution’s retained responsibilities.

13.5 Exit and replaceability

Name the data export format, contract ownership, recovery materials and knowledge required to change a supplier or component. Technology replaceability is not instantaneous substitution. It is the ability to explain dependencies, test a transition and preserve authority and records during it. The review gate accepts a reasoned option comparison and its consequences. Product installation is a later delivery activity.

14 · Transition roadmap, verification and acceptance

14.1 Move through evidence gates

A roadmap is a dependency and risk sequence, not a calendar decorated with milestones. The institution should know what must be learned or demonstrated before the next investment. Durations and budgets are agreed after scope and access are known. The proposed sequence begins with discovery, designs one authoritative journey, pilots it at one office, exercises recovery and expands only after the operating contract works. It preserves an explicit fallback during migration and does not treat data import as proof that business meaning survived.

14.2 Phased delivery

14.3 Migration and coexistence

Identify which source remains authoritative at every stage. Avoid a transition where two applications can approve the same request independently without a reconciliation rule. Plan reference mapping, data quality treatment, cut-over verification and a controlled way to pause or reverse expansion. Historical records may be incomplete. Record their provenance and limitations rather than manufacturing missing approvals. Decide how legacy evidence remains accessible and who may correct it.

14.4 Acceptance scenarios

Acceptance tests require a known initial state and expected result. Keep records of version, environment, scope and observed behaviour. A demonstration on a laptop does not establish production capacity or institutional compliance.

14.5 Handover and closure

Handover includes operating responsibilities, access, runbooks, support expectations, unresolved risks and the next review trigger. The institution accepts the outcome against agreed evidence; completion does not erase open limitations. A delivery phase may be stopped if its assumptions fail. ZAF should make that decision legible before sunk cost turns a weak design into an irreversible commitment.

15 · Future evolution and executive decision package

15.1 Preserve principles, revise implementations

Long-lived architecture does not predict a fixed technology stack decades ahead. It preserves purpose, authority, data meaning and decision history while making implementation choices revisable. An evolutionary trigger should identify the evidence that makes the present option inadequate. The initial modular target may remain appropriate for a long time. It may also need decomposition when ownership or isolation changes. Both outcomes are compatible with ZAF if the decision follows evidence.

15.2 Evolution triggers

No trigger automatically dictates a specific product. Re-evaluate simpler changes and the cost of added operating responsibility.

15.3 Executive decision package

The sponsor receives a concise decision brief linked to the full documentation. It states the institutional promise, observed gaps, recommended target, alternatives, costs to estimate, unresolved authority questions and the evidence needed for the next gate. For this example, management must decide data placement and retention, the approval delegation policy, acceptable network interruption, recovery objectives and the staff able to operate the service. Those decisions cannot be delegated to a diagram.

15.4 Required architecture artifacts

15.5 How ZAF is used in consulting

A scoped review does not promise to complete every chapter for an entire institution in one short engagement. It identifies the decision boundary, required depth and available evidence, then agrees the relevant deliverables. A narrow workflow may need a compact dossier; an institutional platform may need multiple volumes and specialist review. The method’s purpose is a decision that can be explained, implemented and revisited. This public dossier demonstrates the structure and reasoning standard. Its fictional recommendations require adaptation, authority and validation before use in a real organization.

15.6 Closing review

• Can every recommendation be traced to a purpose, constraint or finding?
• Does each authoritative fact and critical service have an owner?
• Are alternatives, consequences and uncertainty explicit?
• Can the team verify, operate and recover the proposed design?
• Do leaders know which decision is theirs and what evidence comes next?

An architecture dossier is ready for decision when these questions have usable answers, not merely when every chapter has text.