Mark the Blueprint as partly withdrawn
The blueprint predates the re-cut and describes Gate House as a running engine. Rather than delete it, mark it — the estate's precedent (zone-engine) is to retain superseded argument as design history. Adds a status banner with a per-section table separating what survives (domain model, authority context, operating modes, posture and credential contracts, MCP doctrine, change dynamics, audit, test program, architectural invariants) from what is withdrawn (component and policy architecture, evaluation order, storage, API surface, caching, deployment, technology direction, reference repository layout, performance, availability, admin interfaces) and what has lapsed (ADR-003; milestones M0, M3, M4). Inline markers on the eight sections most likely to be cited. A revision folding the surviving material into doctrine form is outstanding. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 2564823@bnt-lap001 Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
This commit is contained in:
parent
ebe6032059
commit
e9f29e6551
1 changed files with 63 additions and 2 deletions
|
|
@ -3,9 +3,46 @@
|
|||
**Repository:** `gate-house`
|
||||
**Project family:** NetKingdom
|
||||
**Artifact:** `ArchitectureBlueprint.md`
|
||||
**Status:** Initial architecture blueprint
|
||||
**Status:** Partly withdrawn — see the status banner below
|
||||
**Version:** 0.1
|
||||
**Date:** 2026-08-24
|
||||
**Date:** 2026-08-24
|
||||
**Reviewed:** 2026-08-28 (GH-DEC-2026-001)
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
> ## ⚠ Status: partly withdrawn — 2026-08-28
|
||||
>
|
||||
> This blueprint predates the Gate House re-cut and describes a deterministic
|
||||
> authority plane: a policy decision point with an `/authorize` API, grant
|
||||
> storage, and a revocation service. **That framing was withdrawn** by
|
||||
> `decisions/decisions.md` GH-DEC-2026-001, on the ground that a decision point
|
||||
> inside Gate House would place the deterministic authority boundary inside the
|
||||
> non-deterministic management layer, violating INV-02. `access-engine`
|
||||
> (currently `flex-auth`) is the only policy decision point in NetKingdom.
|
||||
>
|
||||
> The engine-describing sections are retained as **design history**, not as
|
||||
> direction. Do not build from them, and check any section against `INTENT.md`
|
||||
> before citing it.
|
||||
>
|
||||
> | Sections | Status |
|
||||
> |---|---|
|
||||
> | §6 domain model, §7 authority context | **survives** — now the authority context consumed by access-engine |
|
||||
> | §14–15 operating modes | **survives** — assistant and autonomous as security regimes |
|
||||
> | §16 posture, §17 credential separation | **survives** as contracts with kings-guard and secrets-engine |
|
||||
> | §19 MCP integration, §20 change dynamics, §21 circuit breakers | **survives** as doctrine |
|
||||
> | §23 policy self-modification, §24 audit architecture | **survives** as doctrine |
|
||||
> | §34 security test program, §43 architectural invariants | **survives** — §34 as specifications executed by whitehat-security |
|
||||
> | §8–9 decision schema and types | **moves** — the vocabulary stands, ownership is access-engine's |
|
||||
> | §10–13 component architecture, policy architecture, evaluation order | **withdrawn** |
|
||||
> | §25 storage, §26 API surface, §29 caching, §30 deployment | **withdrawn** |
|
||||
> | §31 technology direction, §32 reference repository structure | **withdrawn** |
|
||||
> | §35 performance, §36 availability, §38 administrative interfaces | **withdrawn** |
|
||||
> | §40 ADR-003 (policy engine selection) | **lapsed** |
|
||||
> | §41 milestones M0, M3, M4 | **lapsed** |
|
||||
>
|
||||
> A revision folding the surviving material into doctrine form is outstanding.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -626,6 +663,9 @@ A request must not be allowed to cross a privileged boundary while unresolved.
|
|||
|
||||
# 10. Internal Component Architecture
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
API[Authorization API]
|
||||
|
|
@ -668,6 +708,9 @@ flowchart LR
|
|||
|
||||
# 11. Component Responsibilities
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
## 11.1 Authorization API
|
||||
|
||||
Responsibilities:
|
||||
|
|
@ -877,6 +920,9 @@ Audit storage should be independently controlled.
|
|||
|
||||
# 12. Policy Architecture
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
Gate House should separate policy into layers.
|
||||
|
||||
## 12.1 Baseline Invariants
|
||||
|
|
@ -956,6 +1002,9 @@ Constrains:
|
|||
|
||||
# 13. Policy Evaluation Order
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
A simple initial evaluation order is desirable.
|
||||
|
||||
```text
|
||||
|
|
@ -1482,6 +1531,9 @@ The first implementation may use ordinary storage but should preserve the interf
|
|||
|
||||
# 25. Data Storage
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
Gate House should minimize durable sensitive state.
|
||||
|
||||
## 25.1 Durable State
|
||||
|
|
@ -1512,6 +1564,9 @@ Credential material belongs in Secrets Engine/OpenBao or equivalent backends.
|
|||
|
||||
# 26. API Surface
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
Initial APIs should remain small.
|
||||
|
||||
## 26.1 Authorization
|
||||
|
|
@ -1751,6 +1806,9 @@ Gate House itself should authenticate downstream services using workload identit
|
|||
|
||||
# 31. Technology Direction
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
The architecture should remain implementation-neutral initially.
|
||||
|
||||
Potential choices:
|
||||
|
|
@ -1797,6 +1855,9 @@ Potential:
|
|||
|
||||
# 32. Reference Repository Structure
|
||||
|
||||
> **Withdrawn 2026-08-28** (GH-DEC-2026-001). Retained as design history: this describes Gate House as a running engine. The decision point is `access-engine`.
|
||||
|
||||
|
||||
```text
|
||||
gate-house/
|
||||
├── README.md
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue