The Architecture Review Must End with a Decision

An architecture review is not complete when the meeting ends.

It is complete when an authorized person makes a recorded decision that engineering and operations can implement, test, and revisit.

Slides, diagrams, threat models, control mappings, and questions are inputs. They can improve the decision. They are not the decision.

Review processes are often measured by attendance, agenda completion, or the number of comments left on a document. Those measures show activity. They do not tell a delivery team whether it may proceed, what must change, who owns the remaining work, or which evidence will close the conditions.

A review that ends with "security has concerns" transfers ambiguity to delivery. A review that ends with "looks good" sounds like approval without defining scope, version, assumptions, or operational limits.

The review must end with a decision state, and that state must have consequences.

Start by defining what the review can decide

Before reviewing a design, establish the decision authority and boundary.

A security architect may approve a control pattern, recommend against a risk, or require evidence under a delegated standard. The product owner may accept some operational consequences. A data owner may approve use of a data class. A change authority may permit production implementation. Legal or privacy teams may control obligations that architecture cannot waive.

If nobody in the room has authority to decide the material issue, the meeting is discovery, not a decision review.

I use a small decision vocabulary:

Pending describes workflow, not a final decision. A conditional approval is not a polite deferral. Its conditions must tell a delivery gate whether work may proceed.

Review the exact thing that may be built

A decision without a subject is not durable.

The record should identify:

• service or capability
• architecture revision
• source repository and immutable revision where available
• environment and deployment boundary
• data classifications
• users and machine identities
• external dependencies
• trust boundaries and administration paths
• relevant threat-model revision
• intended release or change
• excluded components and future phases

"Approve the logging platform" is too broad. An approval might cover one read-only connector deployed behind a specific proxy, using a scoped API identity, without response actions. It should not automatically authorize write access, another tenant, raw event export, or a future plugin framework.

A useful subject block is mechanical:

subject:
  service: security-evidence-portal
  architecture_revision: arch-portal-v3
  repository_revision: 7c9d11e-example
  environments: [production]
  deployment:
    listener: loopback-only
    ingress: authenticated-tls-proxy
  data_classes:
    - bounded-security-health-metadata
  authority:
    source_access: read-only
    response_actions: prohibited
  included_connectors:
    - vulnerability-summary
    - siem-health
  excluded:
    - raw-events
    - secret-values
    - endpoint-isolation
    - firewall-mutation

The revision value above is illustrative. In a real record, it should resolve to an immutable artifact or accepted document version.

Scope protects both sides. Engineering knows what has permission to proceed. Reviewers know the approval cannot be stretched into capabilities they did not assess.

Require a review packet that supports a decision

A meeting should not be the first time anyone sees the architecture.

The review packet does not need to be enormous. It needs to answer the questions that change the decision.

NIST SP 800-160 Volume 1 treats systems security engineering as part of a system life cycle rather than an isolated security activity. That is the right boundary for an architecture review. Identity, deployment, operations, maintenance, recovery, and retirement belong in the decision because they belong to the system.

Control catalogs and secure-development guidance are useful inputs, but they do not decide the design. NIST SP 800-53 provides a catalog of security and privacy controls, while the Secure Software Development Framework describes practices for reducing software vulnerabilities. CISA's Secure by Design guidance adds the expectation that manufacturers treat customer security as a core business requirement. The review still has to bind the applicable controls and practices to this system, its owners, and evidence.

The review packet should distinguish planned state from observed state. A proposed firewall rule is not an enforced path. A backup design is not restore evidence. A planned alert is not detection coverage. Label each claim as proposed, implemented, or verified.

Review trust, authority, and failure before product names

I start with six questions:

1. What authority does the system possess?
2. What can reach that authority?
3. Which identities can change the system or its evidence?
4. What sensitive data enters, leaves, or persists?
5. What happens when each dependency is unavailable, compromised, slow, or stale?
6. How is the service safely changed, recovered, and retired?

Only then do product details become useful. Choosing a database or orchestrator does not answer who has administrative authority, which data enters backups, whether admission fails open, or how privileged access is recovered.

A precise review traces authority:

operator
  -> identity provider
  -> deployment system
  -> workload control plane
  -> runtime identity
  -> data service

recovery operator
  -> backup control plane
  -> restore environment
  -> recovered data service

Each arrow needs direction, protocol, authentication, authorization, network enforcement, audit destination, and failure behavior. The recovery path is not a footnote. It can recreate the authority of the production path.

The principle is consistent with the broader approach in Cybersecurity Architect's Handbook, Second Edition: security architecture is about making defensible system decisions across trust, controls, and operations, not decorating a product diagram after implementation.

Write the decision record during the review

A decision should not depend on someone reconstructing the meeting a week later.

I draft the record before the meeting and update it as the review resolves questions. The final form can be YAML, Markdown, or both:

schema_version: architecture.decision.v1
id: ADR-2026-032
title: Deploy read-only security evidence portal
decision: approved-with-conditions
decided_at: 2026-09-09T16:30:00Z
effective_until: null

subject:
  architecture_revision: arch-portal-v3
  repository_revision: 7c9d11e-example
  environments: [production]

context:
  objective: Provide bounded cross-platform health visibility without response authority.
  constraints:
    - native-consoles-remain-authoritative
    - no-raw-security-events
    - no-source-administration-credentials

options:
  - id: O1
    name: Direct browser integrations
    disposition: rejected
    reason: Exposes source paths and authentication material to the client boundary.
  - id: O2
    name: Server-side scheduled collectors with sanitized snapshots
    disposition: selected
    reason: Separates source credentials from the browser and bounds returned data.
  - id: O3
    name: Full automation and response portal
    disposition: rejected-for-current-scope
    reason: Adds mutation authority not required by the objective.

conditions:
  - id: C1
    gate: pre-production
    owner: platform-engineering
    requirement: Application listener accepts connections only on loopback.
    verification: Socket readback and negative connection test from a non-proxy network.
  - id: C2
    gate: pre-production
    owner: security-engineering
    requirement: POST, PUT, PATCH, and DELETE are rejected on every application route.
    verification: Automated method test matrix against deployed release.
  - id: C3
    gate: post-release-7-days
    owner: service-owner
    requirement: Restore the accepted release and sanitized snapshots in an isolated environment.
    verification: Recovery report linked to this decision.

residual_risks:
  - Misleading stale evidence could affect operator judgment.
  - The portal reveals bounded security-system topology to authorized users.

approvals:
  architecture: security-architect
  service: service-owner
  operations: platform-owner

review_triggers:
  - add-mutation-route
  - add-raw-event-storage
  - change-identity-provider
  - expose-application-outside-proxy
  - add-new-data-class
  - material-threat-model-change

A good decision record answers five questions without replaying the meeting:

1. What was decided?
2. What exact subject did the decision cover?
3. Why was this option selected over credible alternatives?
4. What conditions and residual risks remain?
5. What event requires another decision?

Markdown Architectural Decision Records, or MADR, provides an open template and guidance for recording architectural decisions. The template is useful because it keeps context, options, outcome, and consequences together. It still needs local fields for authority, implementation state, security evidence, review triggers, and expiration when those matter.

Conditional approval needs executable semantics

The phrase "approved with conditions" can hide more ambiguity than a rejection.

Every condition needs:

• an identifier
• a specific requirement
• an owner who can perform the work
• a gate such as pre-build, pre-merge, pre-production, post-release, or recurring
• a due date when time-bound
• an evidence type
• a verifier
• failure behavior
• relationship to rollback or service restriction

Consider three conditions:

conditions:
  - id: C-TLS-01
    gate: pre-production
    requirement: All client connections terminate TLS at the approved proxy.
    evidence:
      - deployed-proxy-configuration-readback
      - successful-approved-path-test
      - failed-direct-application-path-test
    on_failure: block-production-route

  - id: C-LOG-02
    gate: post-release
    due_within_hours: 24
    requirement: Administrative events arrive in the central log service.
    evidence:
      - canary-event-id
      - destination-query-result
    on_failure: disable-administrative-feature

  - id: C-REC-03
    gate: recurring
    interval_days: 90
    requirement: Selected service restore completes in an isolated environment.
    evidence:
      - restore-report
      - negative-production-connectivity-tests
    on_failure: open-risk-review-and-freeze-destructive-changes

These conditions have different enforcement points. The first blocks exposure. The second permits a bounded release but disables a feature if evidence does not arrive. The third affects ongoing operational authority. Flattening them into one checklist loses the decision logic.

A post-release condition is a temporary security exception if the standard control is absent during that period. It should use the same owner, expiration, compensating-control, and risk-acceptance discipline described in Security Exceptions Are Architecture Decisions with Expiration Dates.

Make approval and implementation separate states

An approved design is not an implemented design.

I track at least these states:

proposed -> reviewed -> decided -> implementation-ready
                              -> implemented
                              -> verified
                              -> operating
                              -> superseded or retired

The transitions are evidence-bearing.

This vocabulary prevents an approval badge from becoming false operational evidence.

A design can be approved and never built. It can be built differently from the approved revision. It can match the approved configuration but fail its negative tests. It can pass release acceptance and later drift. Each condition needs a different response.

Negative tests belong in the decision

Positive tests prove the intended path can work. Negative tests help prove that unintended paths do not.

An architecture acceptance matrix should include both:

The matrix should name where the test runs. Testing a firewall from the same allowed subnet proves little about prohibited source zones. Testing authorization only through a user interface does not prove direct API enforcement. Testing a backup checksum does not prove service recovery.

The architecture review is the right place to define these evidence boundaries because they follow directly from the trust model.

Review failure modes and rollback as architecture

Rollback is often left to the deployment plan, but the ability to reverse a design depends on architecture.

A database migration may be backward compatible for application code but not for data already transformed. A new identity provider may preserve local break-glass access but invalidate existing sessions. A network cutover may be reversible until DNS, certificates, or client caches cross a point of no return. A new backup format may require the old reader for recovery.

The decision should record:

• reversible and irreversible steps
• rollback deadline
• retained prior artifacts and credentials
• data conversion behavior
• compatibility window
• state reconciliation after rollback
• monitoring that triggers rollback
• authority to order rollback
• recovery path if rollback itself fails

A bounded rollout plan might be:

release:
  canary_scope: one-noncritical-instance
  observation_minutes: 30
  expansion_requires:
    - error-rate-within-baseline
    - authorization-negative-tests-pass
    - required-events-visible
  rollback_triggers:
    - unexpected-privileged-action
    - prohibited-data-in-output
    - loss-of-authoritative-audit
  rollback_deadline: before-schema-v2-write
  retained_artifacts:
    - prior-container-digest
    - prior-config-bundle
    - database-snapshot-reference
  freeze_on_rollback_failure: true

The review should challenge whether those artifacts can actually restore service. The prior container digest is not useful if the registry retention policy deletes it. A database snapshot is not enough if restore credentials or encryption keys live in the failed control plane.

Use policy as a guardrail, not as the architect

JSON Schema, Open Policy Agent, Conftest, and CI can validate decision-record structure and compare deployment metadata with approval scope. They are useful for mechanical facts:

• required fields exist
• decision state is allowed
• approvers are present for the risk tier
• blocking conditions are closed before deployment
• architecture revision matches release metadata
• approval has not expired
• service and environment remain in scope
• required evidence references resolve
• prohibited wildcard scopes are absent

A policy input might look like this:

{
  "decision": {
    "id": "ADR-2026-032",
    "state": "approved-with-conditions",
    "architecture_revision": "arch-portal-v3",
    "environments": ["production"],
    "open_blocking_conditions": 0
  },
  "release": {
    "architecture_revision": "arch-portal-v3",
    "environment": "production",
    "adds_mutation_routes": false,
    "adds_data_classes": []
  }
}

Policy can deny a revision mismatch. It cannot decide whether the proposed trust boundary is wise. It can require a threat-model reference. It cannot determine whether the model describes reality. It can ensure a rollback field exists. It cannot prove the rollback works.

Automation protects decision integrity after humans make the architectural judgment.

Open-source tools can support the record

The decision process should survive a tool change. Keep the record in a portable format and treat visual or workflow platforms as views and integrations.

Mermaid is MIT licensed, PlantUML uses the GPL, D2 uses MPL-2.0, and Graphviz uses the Eclipse Public License 2.0 according to their project materials. Verify the exact version and use when licensing affects distribution.

A large portal can improve discoverability while increasing the number of components needed to make one decision. I start with Markdown, structured metadata, source control, and a validation job. I add a catalog or workflow system when ownership, search, integration, and reporting justify its operational cost.

Review the decision itself

Before closing, test the record as if someone unfamiliar with the meeting will use it six months later.

Decision quality checklist

• The deciding authority is named and has scope to decide.
• The subject resolves to an exact architecture revision.
• Included and excluded environments, services, data, and capabilities are explicit.
• Credible alternatives and reasons are recorded.
• Trust, administration, recovery, and external paths are represented.
• Residual risks have owners with appropriate authority.
• Conditions use binary or bounded acceptance criteria.
• Every condition has an owner, gate, evidence, verifier, and failure action.
• Recommendations are not disguised requirements.
• Assumptions and limitations are visible.
• Positive and negative tests cross the claimed boundaries.
• Rollback and rollback failure are addressed.
• Review triggers and supersession rules are defined.
• Approval is not presented as implementation or verification evidence.

Negative decision tests

Try to misuse the approval:

1. Reference it from a different environment.
2. Add a service not named in scope.
3. Add a new data class.
4. Add a mutation route to a read-only design.
5. Use a newer architecture revision with the old decision.
6. Leave a blocking condition open.
7. Remove the owner after approval.
8. Trigger a material threat-model change.
9. Restore an old approved configuration after the decision was superseded.
10. Use repository approval from someone without decision authority.

Each case should fail or force review. If the record can authorize all of them, it is not a bounded decision.

Close the loop after release

The final architecture review decision creates obligations beyond the meeting.

After implementation:

1. read back the deployed configuration
2. run the positive and negative acceptance matrix
3. verify logging, monitoring, ownership, and on-call routing
4. exercise rollback within its valid window
5. reconcile actual state with the approved revision
6. close conditions only with their named evidence
7. update the threat model with observed state
8. declare the service operating, restricted, rolled back, or failed

This is where architecture becomes operational evidence.

A decision that cannot be verified is too vague. A decision that cannot be rolled back may still be necessary, but it needs stronger canaries, recovery, and authority. A decision that nobody can find will be made again by someone with less context.

The architecture review earns its cost when it reduces ambiguity at the point of change.

End with one of the defined states. State exactly what was reviewed. Make conditions executable. Name who owns the consequences. Record what would invalidate the approval. Then connect the decision to deployment, verification, operation, and recovery.

The meeting can end on time. The architecture review ends when the decision can survive it.