# Authority-plane Blueprint retirement

**Repository:** `gate-house`
**Project family:** NetKingdom
**Status:** Design history; non-normative
**Date:** 2026-09-01
**Decision:** `decisions/decisions.md` GH-DEC-2026-001
**Workplan:** GH-WP-0001-T05

## Purpose

This note records the retirement of `ArchitectureBlueprint.md` v0.1 and the
disposition of its sections. It prevents withdrawn engine design from remaining
in the working architecture while preserving the original argument and text.

The complete pre-revision document is recoverable without copying 2,500 lines
of obsolete direction into current documentation:

```text
git show 75ce372:ArchitectureBlueprint.md
```

Commit `75ce372` is the T04 completion and contains the last complete v0.1
Blueprint before T05 began.

## Why it was retired

Version 0.1 described Gate House as a deterministic authority plane with an
`/authorize` API, policy evaluation, grants, revocation, storage, deployment,
and operational targets. GH-DEC-2026-001 rejected that placement: Gate House is
non-deterministic Staff, while access-engine is the only policy decision point.

Building the old design in this repository would have violated the doctrine's
first boundary in its own home: cognition would have acquired a path to
privilege.

## Section disposition

| v0.1 section | Disposition in v0.2 |
| --- | --- |
| §1–4 purpose, goals, non-goals, context | Rewritten around a Staff-layer doctrine artifact and the estate responsibility boundary. |
| §5 three-plane model | Replaced by the accepted Taxonomy → Tooling → Engines → Staff layer model. Gate House's former Authority Plane placement is withdrawn. |
| §6 core domain model | Retained and tightened in v0.2 §3. Runtime-owned grant and decision terms are explicitly attributed to access-engine. |
| §7 canonical authorization request | Replaced by `docs/contracts/authority-context.md`; no Gate House wire format or endpoint. |
| §8–9 canonical decision and decision types | Decision vocabulary retained; schema and emission belong to access-engine. |
| §10–13 components, policy architecture, evaluation order | Withdrawn as access-engine implementation design. The monotonic-restriction invariant survives without prescribing an algorithm. |
| §14–15 Assistant and Autonomous modes | Retained as security regimes in v0.2 §5. Gate House is removed from runtime flows. |
| §16 King's Guard integration | Retained as the restrictive posture and containment contract in v0.2 §8. |
| §17 secrets/OpenBao integration | Retained as responsibility and credential-separation doctrine in v0.2 §9. Direct Gate House integration is withdrawn. |
| §18 execution gateway | Retained as a preference for trusted brokered execution, owned by the execution and credential repositories. |
| §19 MCP integration | Retained as capability-not-authority doctrine in v0.2 §10. |
| §20–21 change dynamics and circuit breakers | Retained as the Change Dynamics Envelope and independent stop-path obligations in v0.2 §11. Runtime mechanisms belong to Engines. |
| §22 multi-tenancy | Retained as explicit-scope doctrine in v0.2 §12. |
| §23 policy self-modification | Retained as independent-governance doctrine in v0.2 §12. |
| §24 audit architecture | Retained in v0.2 §13, corrected with the archive-completeness bound and per-source emission ownership. Gate House as audit writer is withdrawn. |
| §25–26 storage and API | Withdrawn completely as Gate House runtime design. |
| §27 trust boundaries | Replaced by v0.2 §2. Gate House is outside the runtime trust path. |
| §28 failure modes | Retained as cross-component doctrine in v0.2 §14, with local-outbox revocation semantics from GH-DEC-2026-002. |
| §29 caching | Implementation ownership moved to consuming Engines; only the no-expansion-on-staleness rule survives. |
| §30–32 deployment, technology, repository layout | Withdrawn completely. Gate House is specification-only. |
| §33 end-to-end scenarios | Reconciled to INTENT's UC-01…UC-05 and referenced by v0.2 §16. |
| §34 security test program | Reconciled to the Canon's T-01…T-10. Gate House specifies; whitehat-security executes. |
| §35–38 performance, availability, observability, admin UI | Withdrawn as service requirements. Cross-estate evidence and failure obligations survive without Gate House SLOs or interfaces. |
| §39 governance integration | Mandate model retained as a logical governance shape in v0.2 §6, not a Gate House database schema. |
| §40 ADR backlog | Reclassified in v0.2 §17. ADR-003 lapsed; Engine implementation choices moved to their owning repositories. |
| §41 prototype milestones | M0, M3, and M4 lapsed. Remaining concerns are doctrine, owning-repository work, or assurance targets rather than Gate House implementation milestones. |
| §42 longer-term evolution | Replaced by INTENT success criteria and the conformance loop. |
| §43 invariants | Stable A-01…A-15 identifiers retained and corrected for ownership in v0.2 §15. |
| §44 summary | Replaced: Gate House establishes doctrine and no longer appears in the request path. |

## What retirement means

The v0.1 text remains useful evidence of why the boundary was redrawn. It is
not an implementation backlog. Citations to it must identify it as historical;
new architecture and workplans cite v0.2, the authority-context contract, the
Canon, or the governing decision.