ADR 0015 — Separate Architecture Decision, Implementation And Verification¶

Status: ACCEPTED
Date: 2026-08-25
Supersedes: any practice that lets one implementation slice redefine the architecture rule used to approve itself
Decision owner: Product architecture review

Context¶

Recent Logistics Workspace work repeatedly created customer/cohort-named backend files, speculative runtime or package scaffolding and implementation-specific architecture tests. The repository already stated many correct principles, but the active Task could amend Product/phase/Task/manifest/code/test and validation together. A wrong premise could therefore become internally consistent and pass.

The immediate example is treating the first Trade/Inventory validation tenant as a backend owner. CTC and MK are tenants and operating-profile cohorts; Commercial, Fulfillment, Scale, Inventory, Transportation and Settlement are the shared semantic owners.

Decision¶

Adopt ../architecture/ARCHITECTURE_CHANGE_METHOD.md as the binding process for architecturally significant changes.

Evidence mapping, shaping, architecture review, implementation and verification are separate passes.
A production implementation slice may not modify architecture authority or architecture/admission validators.
A governance slice may not modify Product runtime source.
New packages/public exports/customer-specific backend boundaries default to a zero budget.
Architecture changes require a previously accepted ADR with at least three serious options.
Stable fitness functions enforce Product/module principles; Task-specific tests may not redefine those principles.
First validation tenants are recorded as cohorts, never module/package/writer owners.
Structural cleanup reports net complexity, not only added-line and changed-path counts.

Alternatives¶

Alternative A — Add more startup context and a longer plan¶

Rejected. More detail reduces omissions but does not validate the starting premise. It can make the wrong design more coherent and harder to challenge.

Alternative B — Add more fields to the active Task manifest¶

Rejected as the sole control. A self-authored manifest can still justify its own abstraction and test. Machine fields are useful only after an independently accepted architectural decision.

Alternative C — Separate roles and use stable architecture fitness functions¶

Accepted. This creates an independent decision point, prevents implementation from changing its own rules and measures whether complexity actually decreases.

Alternative D — Central architecture team approval for every code change¶

Rejected for the current operating scale. It would add excessive queueing. Review is required only for difficult-to-reverse structural decisions; ordinary vertical implementation remains Task-owned.

Consequences¶

Positive:

customer/cohort names are less likely to become backend architecture;
architecture tests protect stable rules instead of implementation artifacts;
cleanup is measured by reduced structural complexity;
Cloud/macro review can remain read-only until an implementation decision is approved;
implementation Tasks become smaller and easier to verify.

Negative:

architecture changes require an extra decision pass;
some existing tenant-specific debt remains temporarily as a frozen exception;
urgent structural changes may take longer than a direct patch;
reviewers must maintain current system/module maps and debt exceptions.

Revisit triggers¶

Revisit when one of the following is proven:

the process blocks ordinary non-architectural changes;
accepted decisions routinely lack enough information for implementation;
stable fitness functions produce persistent false positives;
team scale requires explicit human ownership beyond role-separated passes;
configuration-only onboarding is accepted and changes the tenant/profile boundary.

---¶

Source: new-system/docs/decisions/0015-architecture-change-control.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.