gate-house/ArchitectureBlueprint.md

# Gate House — Architecture Doctrine Blueprint

**Repository:** `gate-house`
**Project family:** NetKingdom
**Artifact:** `ArchitectureBlueprint.md`
**Status:** Current — doctrine architecture; no runtime role
**Version:** 0.3
**Date:** 2026-09-10
**Decision:** `decisions/decisions.md` GH-DEC-2026-001

---

## 1. Purpose and authority

This document describes the architecture of NetKingdom security doctrine: the
responsibility boundaries, semantic contracts, invariants, and conformance
loop Gate House maintains. It does not specify a Gate House service. Gate House
has no request-time position, stores no runtime state, and renders no
authorization decision.

The v0.1 Blueprint described Gate House as a deterministic authority plane.
That design was withdrawn by GH-DEC-2026-001 because it put the deterministic
decision point inside a non-deterministic Staff repository. Its disposition is
recorded in
[`history/2026-09-01-authority-plane-blueprint-retirement.md`](history/2026-09-01-authority-plane-blueprint-retirement.md),
and the complete historical text remains available at Git object
`75ce372:ArchitectureBlueprint.md`.

This document is subordinate, in order, to:

1. `decisions/decisions.md`;
2. `spec/ActiveSecretsManagementCanon_v0.3.md`;
3. `INTENT.md`;
4. the accepted NetKingdom security-layer standard.

Where they conflict, the higher artifact wins and this Blueprint must be
corrected.

The architectural maxim is:

> **Cognition proposes. Authority disposes. Infrastructure executes.**

## 2. Architectural shape

NetKingdom separates security responsibilities by determinism and artifact:

```text
Taxonomy  names the concepts and semantic contracts
    ↓
Tooling   holds consistent, performant, scalable state
    ↑
Engines   expose deterministic APIs over modeled concepts
    ↑
Staff     proposes doctrine, plans, changes, and supervision
```

The arrows are dependency direction, not authority flow. Staff acts through
Engine APIs and never reaches Tooling directly.

For a protected action, the architecture is:

```text
human / agent / workload proposes an action
    ↓
identity and context engines supply authoritative facts
    ↓
access-engine renders a deterministic decision
    ↓ GRANT only
secrets-engine materializes target-specific authority when needed
    ↓
ops-warden / resource-side enforcement executes within the grant
    ↓
evidence sources emit records; audit-core protects accepted records
    ↓
kings-guard observes posture and findings; whitehat-security challenges controls
```

Gate House is outside this runtime path. It specifies what each boundary must
mean and reviews whether the path conforms.

### 2.1 Responsibility boundary

| Component | Architectural responsibility |
| --- | --- |
| info-tech-canon / NetKingdom canon | shared terminology and standards of record |
| key-cape | authentication, federation, and identity tooling profile |
| user-engine | authoritative user, account, and membership facts |
| tenant-engine | authoritative tenant and organizational facts |
| zone-engine | authoritative zone identity and membership facts |
| access-engine | the only policy decision point; evaluates access rules |
| secrets-engine | credential abstraction, custody, and lifecycle |
| OpenBao | protects and issues secret, lease, and PKI material |
| ops-mason / ops-warden | construct and operate access lanes and perimeters |
| kings-guard | observation, bounded posture, findings, and containment requests |
| whitehat-security | adversarial execution of assurance specifications |
| Gate House | doctrine, authority context, invariants, conformance, and curriculum |

Two boundaries are lexical as well as architectural:

- an **access lane** says how a worker reaches a host and belongs to ops-mason
  and ops-warden;
- an **access rule** says whether an action may occur and belongs to
  access-engine.

## 3. Core domain model

Gate House fixes the following meanings. Owning engines choose storage and wire
representations without changing the semantics.

| Term | Meaning |
| --- | --- |
| **Principal** | Human, organization, workload, or system on whose behalf authority originates. |
| **Actor** | Entity directly attempting the action. |
| **Runtime Identity** | Concrete workload instance performing execution. |
| **Tenant** | Security and organizational domain in which the action occurs. |
| **Environment** | Governed operational environment containing the target. |
| **Mandate** | Standing organizational authorization defining what an autonomous actor is intended to do. |
| **Delegation** | Scoped transfer of authority that preserves principal and actor and does not widen authority. |
| **Authority Ceiling** | Maximum authority an actor can obtain. |
| **Operating Mode** | Assistant or Autonomous security regime. |
| **Task** | Bounded unit of work for which authority is requested. |
| **Action** | Canonical operation requested of a protected resource. |
| **Resource** | Canonical target of an action. |
| **Posture** | Bounded security-state input from a trusted source. |
| **Decision Evidence** | Record of the identities, inputs, policy, conditions, and result that produced a decision. |
| **Credential Binding** | Mapping from granted authority to the mechanism a target accepts. |

A mandate is not a credential, a task is not a mandate, identity is not
authorization, and a credential is not the source of authority.

Access-engine renders `GRANT`, `DENY`, `REQUIRE_APPROVAL`, or `DEFER`.
Gate House defines the vocabulary and invariants of those outcomes but neither
evaluates nor emits them.

## 4. Authority context contract

The normative logical contract is
[`authority-context.v1`](docs/contracts/authority-context.md), recorded by
[ADR-001](docs/adr/ADR-001-canonical-authority-context-contract.md) and
[ADR-002](docs/adr/ADR-002-principal-actor-runtime-identity-model.md).

Every agentic authority request must be able to express:

```text
principal
actor
runtime identity
tenant
environment
mandate
task
operating mode
```

These are input claims alongside verified identity claims, requested action and
resource, authoritative resource facts, policy, approval, posture, and limits.
No field grants authority by being present. Caller assertion must remain
distinguishable from authoritative evidence.

Principal, actor, and runtime identity are separate semantic roles. They may
resolve to the same subject in a legitimate direct operation, but a consumer
must not copy one into a missing role or use one generic identifier to erase
delegation and runtime attribution.

Missing, conflicting, stale, or unresolvable security-critical context fails
closed. `DEFER` is reserved for non-security-critical enrichment and is not a
substitute for evidence needed to decide a protected operation.

## 5. Agentic operating modes

Operating mode is a security regime, not a deployment label.

### 5.1 Assistant

A human is actively engaged and can observe, redirect, approve, or stop at
human latency.

- the human remains principal;
- the agent remains an identifiable actor;
- the concrete agent session or workload remains identifiable as runtime;
- privileged authority is bound to active supervision and short lifetime;
- the human's reusable credentials are not copied into agent context;
- interruption and confirmation remain available for high-impact actions.

Human disconnect, session timeout, or loss of supervision must not silently
convert an Assistant workflow into privileged Autonomous operation.

### 5.2 Autonomous

A scheduled, triggered, or event-driven actor runs without continuous human
supervision.

It requires:

- a unique actor identity and concrete runtime identity;
- a named governance owner;
- an explicit, current mandate and bounded task;
- an authority ceiling and tenant, environment, resource, and action bounds;
- runtime, concurrency, tool-call, token, compute, and credential-TTL bounds;
- an independent kill switch and lifecycle termination path;
- protected evidence sufficient for reconstruction;
- no borrowed human credential.

### 5.3 Transition

A transition from Assistant to Autonomous is a governed change. It requires a
new authority request under the Autonomous requirements; it is not a mutation
or fallback of an in-flight Assistant context.

## 6. Mandates, delegation, and ceilings

A mandate is a governed declaration of why an autonomous actor exists. A
logical mandate includes, at minimum:

```yaml
id: mandate:release-automation
revision: 7
owner: team:platform-release
purpose: deploy approved releases
operating_mode: autonomous
lifecycle:
  starts_at: 2026-09-01T00:00:00Z
  expires_at: 2026-12-01T00:00:00Z
  termination_ref: kill-switch:release-automation
authority_ceiling:
  tenants: [tenant:platform]
  environments: [production]
  actions: [release.deploy]
  resources: [k8s://cluster-a/ns/payments/*]
constraints:
  max_runtime: 30m
  max_concurrency: 1
  max_mutations_per_task: 1
```

This is a logical governance shape, not a Gate House storage schema.
Access-engine owns how the authoritative mandate reference becomes policy
input.

Delegation attenuates:

```text
child authority ⊆ delegated authority ⊆ principal authority ⊆ authority ceiling
```

No agent reasoning, tool availability, approval, posture, budget, or child
delegation may widen the ceiling.

## 7. Deterministic authority boundary

Every privileged action crosses an access-engine or resource-side deterministic
authority boundary. The same authoritative input state and policy version must
produce the same decision.

The decision must be able to account for:

```text
WHO          principal, actor, runtime identity
WHERE        tenant, environment, zone, resource
WHAT         action and normalized parameters
WHY          task, mandate, delegation
UNDER WHICH  policy, approval, posture, quotas, budgets, ceiling
UNTIL WHEN   expiry and credential TTL
```

Evaluation is monotonic toward restriction: after application of the authority
ceiling, no later input may create authority beyond it. This is a property Gate
House specifies and access-engine implements; it is not a prescribed policy
algorithm or evaluation order.

Approval is an independently governed, actor/action/resource/parameter/time
binding. It can satisfy an explicit approval requirement but cannot exceed the
authority ceiling or compensate for invalid identity, mandate, tenant, or
environment context.

## 8. Posture and containment contract

King's Guard publishes bounded posture observations. Access-engine maps trusted
posture to deterministic restrictions. Gate House owns the asymmetry:

> **Posture may reduce authority, require stronger authorization, or request
> containment. It must not probabilistically manufacture additional
> authority.**

Accepted direction:

```text
King's Guard observes DEGRADED / SUSPICIOUS / CONTAIN
    ↓ bounded posture with source, subject, freshness, and reason
access-engine applies a versioned deterministic rule
    ↓
authority stays equal or becomes narrower
```

Forbidden direction:

```text
adaptive system says “looks safe”
    ↓
new or wider authority
```

A containment request does not authorize containment. Access-engine decides
whether it may occur; ops-warden or the responsible Engine performs the
authorized action. If posture is unavailable or stale, configured fallback
must not expand authority over the last authoritative state or baseline policy.

## 9. Authority, credentials, and execution

The responsibility chain is:

```text
access-engine   decides whether authority exists
secrets-engine  selects how granted authority is materialized
OpenBao         protects and issues credential material
ops-warden      operates the access lane or trusted execution path
resource        independently enforces the presented authority
```

Credential invariants:

- credentials are issued only after authority exists;
- credential scope and audience do not exceed the grant;
- credential lifetime does not exceed the authority lifetime;
- revocation and expiry semantics remain linked;
- raw reusable credentials do not enter model context;
- trusted brokered execution is preferred to disclosing credentials to an
  agent;
- Gate House never accesses OpenBao or another Tooling system directly.

An unavailable credential mechanism means execution cannot proceed. It does
not cause another component to invent authority or silently substitute a
broader credential.

## 10. MCP and tooling doctrine

MCP is a capability interface, not an authority system. Tool discovery means
that an operation exists; it does not mean the actor may invoke it.

A sensitive tool definition should provide enough stable metadata for a PEP to
construct a normalized request:

```yaml
tool: restart_service
action: kubernetes.deployment.restart
resource_schema: k8s-resource.v1
parameter_schema: restart-service.v1
risk_class: privileged-write
reversible: true
```

The enforcement path is:

```text
agent selects tool
    ↓
MCP server / resource PEP constructs normalized request
    ↓
access-engine decision
    ↓ GRANT only
separately issued, resource- and audience-bound authority
    ↓
tool execution and evidence emission
```

Inbound-token passthrough is forbidden by default. The downstream resource
must receive authority intended for that resource, not whatever ambient token
the caller happened to possess.

## 11. Change Dynamics Envelope

Agentic systems can exceed human review speed even while each individual action
looks ordinary. The Change Dynamics Envelope bounds the cumulative rate, scope,
concurrency, and duration of change.

Dimensions include:

- concurrent mutating actors and actions per grant;
- resources per task and mutations per resource;
- task duration, credential TTL, and agent-chain depth;
- deployment frequency and destructive-action quota;
- tenant, environment, repository, and resource-class boundaries;
- read/write and reversible/irreversible action separation;
- token, compute, tool-call, and external-service spend.

Hard limits such as authority ceilings, production concurrency, destructive
quotas, and environment boundaries are deterministic enforcement inputs. Soft
signals such as cost warnings and anomaly recommendations may ask for review or
reduce authority, but do not grant it.

Economic budgets are useful blast-radius controls. They are never
authorization.

### 11.1 Independent stop paths

Autonomous write authority must be stoppable without actor cooperation.
Depending on the owning Engine, the deterministic mechanisms may suspend an
actor or mandate, revoke grants and credentials, restrict an environment to
read-only, or require approval for mutations.

Degradation moves toward restriction:

```text
NORMAL → RESTRICTED → READ_ONLY → BLOCKED
```

Diagnostic visibility should remain available longer than mutation authority
where policy can safely separate them.

## 12. Tenant isolation and policy self-modification

Tenant context is explicit for protected actions. An omitted tenant is not a
wildcard, and a platform actor does not receive implicit cross-tenant authority.
Tenant, environment, resource, and action bounds compose by intersection.

Changes to authority ceilings, policy packages, identity trust, tenant mapping,
approval rules, posture mapping, audit configuration, credential bindings, or
kill switches require stronger and independently governed authorization than
ordinary workload changes.

An actor must not have routine authority to widen the policy that constrains
itself. An attempted self-escalation is denied and emitted as high-value
security evidence.

## 13. Decision evidence and audit

Decision evidence must support reconstruction of:

- principal, actor, runtime identity, tenant, environment, task, and mandate;
- action, resource, and normalized-parameter digest;
- operating mode, approval, and posture inputs;
- authority ceiling, quotas, budgets, and expiry;
- policy identifier and version;
- decision, reason, grant or approval references, and credential binding;
- execution target, result, and relevant state transition.

The actor being audited must not be able to alter or erase authoritative
evidence. Each owning system emits evidence for its own state transitions;
Gate House is not a central runtime audit writer.

### 13.1 Completeness bound

An append-only archive with a verified hash chain proves that records it holds
were not altered or truncated after arrival. It cannot prove a record was ever
sent. Therefore:

- completeness is the emitting system's obligation;
- load-bearing evidence emission is atomic with the state change, normally by
  a local transactional outbox;
- heartbeat and reconciliation make silent omission detectable where required;
- no conformance claim says merely that “the audit record proves it happened.”

The approval evidence contracts are the reference application:

- [`approval-outbox.md`](docs/contracts/approval-outbox.md);
- [`approval-emission-detection.md`](docs/contracts/approval-emission-detection.md);
- [`approval-consumption.md`](docs/contracts/approval-consumption.md).

## 14. Failure semantics

Security-critical ambiguity fails closed.

| Failure | Required architectural outcome |
| --- | --- |
| access-engine or required policy unavailable | Protected operation denied. |
| identity, tenant, environment, mandate, or delegation unresolved | Denied when the fact is security-critical. |
| posture unavailable or stale | Configured restrictive fallback; never additional authority. |
| approval unavailable, invalid, revoked, consumed, or mismatched | Approval-dependent operation denied. |
| credential materialization unavailable | No credential-dependent execution; the decision is not widened or replaced. |
| protected evidence cannot be durably coupled to a state change | That state change does not commit. |
| evidence archive unavailable after a local outbox commit | Retry asynchronously; do not roll back the committed safety action. |
| stale cache conflicts with newer restriction or revocation | New authority denied; caches must not outlive their safe staleness policy. |

Fail closed does not mean one global availability rule. Each state owner must
make the safety transition and its evidence atomic locally so an unavailable
archive cannot block emergency revocation.

## 15. Architectural invariants

These stable identifiers retain the v0.1 Blueprint's invariant lineage, now
stated against the correct ownership boundary.

### A-01 — No probabilistic privilege

No LLM or statistical component is the final source of privilege.

### A-02 — Explicit actor

Every privileged action resolves to an explicit actor.

### A-03 — Autonomous mandate

Every autonomous privileged action resolves to an explicit current mandate.

### A-04 — Attenuating delegation

Delegated authority does not exceed parent authority or the authority ceiling.

### A-05 — Explicit tenant scope

Every protected action has explicit tenant or estate-defined non-tenant scope.

### A-06 — Deterministic protected boundary

Production mutations cross deterministic access-engine or resource-side
policy enforcement.

### A-07 — Bounded lifetime

Authority and its credential material do not outlive their configured expiry.

### A-08 — Independent revocation

Emergency reduction or revocation does not depend on the affected actor
cooperating.

### A-09 — Restrictive posture

Adaptive posture may restrict authority but cannot probabilistically create
new authority.

### A-10 — Credential separation

Credentials represent granted authority; they are not its source.

### A-11 — Protected ceiling

Actors cannot ordinarily modify the controls defining their own authority
ceiling.

### A-12 — Actor-resistant evidence

Authoritative evidence is protected from the actor being audited, subject to
the completeness bound in §13.1.

### A-13 — Restrictive failure

Failure of a security-critical dependency does not silently expand authority.

### A-14 — No accidental autonomy

Assistant sessions do not silently become Autonomous sessions.

### A-15 — Incorrect-agent tolerance

Deterministic boundaries continue to hold when every agent behaves incorrectly.

### A-16 — Distinguishable routes

Where one observable state is reachable by two routes that differ in security
meaning, the record distinguishes which route produced it.

The two routes usually behave identically, and must — `unknown` and `absent` both
fail closed, and should. A-16 is not a requirement that they diverge; it is a
requirement that a later reader can tell them apart. Where they cannot, a sound
check gets read as establishing a property it does not carry, and the safer
reading of the appearance becomes unavailable to everyone.

Instances: `GH-DEC-2026-010` (a decision envelope reads identically whether
`access-engine` issued it or a responder forged it), `GH-DEC-2026-011` (`unknown`
versus `absent` in a stance map), `GH-DEC-2026-013` (a `tenant` claim
directory-asserted about the principal versus registration-supplied about the
client, and — `key-cape`'s own extension — a third route where nobody asserted a
zone and a profile default supplied it), `GH-DEC-2026-014` (*erased* versus
*never held* on an evidence path).

**Rider — who writes the marker.** A-16 is only as strong as the independence of
the party that writes the route marker from what the marker asserts. Where the
marker is written by the party whose conduct the route describes, **A-16
constrains a defect but not an adversary, and MUST NOT be read as establishing the
distinction against a compromised source.**

The four instances are not equally strong and the register should say so: a
signature by the issuer is independent of the party relying on it; a PEP labelling
its own input gains nothing by mislabelling; a tenant provenance written by the
issuer is independent of the consumer; and an *erased*-versus-*never-held* marker
written by the party the evidence is about is a **self-attestation**. The last
reduces to the residual `informed-decision` has twice been refused credit for
closing, and `GH-DEC-2026-014` §4 narrows it — non-production becomes attributable
— without removing it, because the attribution still rests on that party's own
marker.

Without this rider A-16 becomes the thing it exists to prevent: a sound check read
as establishing a property it does not carry. Raised by `informed-decision`
against its own instance, which is the weak one.

### A-17 — Fail-closed transitions

A transitional deviation from an invariant is admissible only where it fails
closed on the case that distinguishes it from the conformant state.

This governs what may enter the declared-gap register rather than what a system
does at runtime. The admitting question is not the quality of the design or the
length of the transition, but the direction of failure at the distinguishing
case. A promise that fails open is a permission; a promise that fails closed is a
gap.

**Precondition — the distinguishing case must be observable first.** A-17 asks
which way a case fails, and that question is unanswerable where the case cannot be
seen. **Where the distinguishing case is not observable, making it observable is a
precondition of applying A-17, not an outcome of it.** Otherwise A-17 admits
anything whose distinguishing case is merely invisible, which reads as failing
closed because nothing visibly fails.

**A-17 therefore depends on A-16.** One cannot ask which direction a case fails in
until the record can distinguish that case from its neighbours.

Instances: `GH-DEC-2026-011` (a dated transitional `unknown: fail_open` declined
— its distinguishing case is exactly where it fails open, so the transition
licenses the forbidden thing and dates it), `GH-DEC-2026-013` (a
registration-bound tenant granted — registration and directory disagreeing
refuses issuance rather than picking a winner), `GH-DEC-2026-014` (commitment-only
evidence granted — but **only after** §4 made the case observable; as proposed it
had no failure direction at all, because a reviewer receiving a blank could not
tell *erased* from *withheld* from *lost* from *never held*).

The third instance is why the precondition is stated. `GH-DEC-2026-014` §4 did not
**test** the direction of failure; it **manufactured** one, by requiring an
existence assertion that turns non-production into a finding. That was the right
outcome reached without noticing it was a different operation from the one A-17
describes. Raised by `informed-decision`, from the instance it bears.

**A-16 and A-17 are newer than A-01…A-15 and are not yet estate doctrine.** They
are stated here because a property recorded only against the instance that
produced it is found by accident or not at all. Graduation to
`net-kingdom/canon/standards/` waits on a repository bearing a cost under them
having argued them, which is the bar `security-layer-model` met and these have
not.

## 16. Conformance architecture

Gate House doctrine is real only when the loop turns:

```text
Gate House asserts an invariant or contract
    ↓
owning Engines and Staff repositories implement it
    ↓
whitehat-security executes the assurance specification
    ↓
kings-guard observes behavior and findings
    ↓
findings return to Gate House as doctrine change
```

The Canon's T-01…T-10 are specifications owned by Gate House and executed by
whitehat-security. They cover malicious-model behavior, credential
exfiltration, human disconnect, policy self-modification, confused-deputy
behavior, approval replay, circuit breakers, evidence reconstruction, audit
failure, and revocation closure.

Their executable handoff is
[`asm-assurance-targets.v1`](docs/assurance/asm-t01-t10-executable-targets.md).
Results return under
[`conformance-reporting.v1`](docs/contracts/conformance-reporting.md), and the
kings-guard observation half follows
[`posture-findings-return.v1`](docs/contracts/posture-findings-return.md).

The reference scenarios are:

- UC-01 — human-assisted read;
- UC-02 — autonomous release;
- UC-03 — dynamic database access;
- UC-04 — containment;
- UC-05 — self-escalation attempt.

Passing prose review is insufficient. A conformance report names the invariant,
owning implementation, test or observation, evidence bound, result, and finding
return path.

## 17. ADR disposition and remaining doctrine work

| ADR | Disposition |
| --- | --- |
| ADR-001 | Accepted — canonical authority-context contract. |
| ADR-002 | Accepted — principal / actor / runtime identity model. |
| ADR-003 | Lapsed — policy-engine selection belongs to access-engine. |
| ADR-004, ADR-005, ADR-008, ADR-011, ADR-012 | Engine implementation decisions; no Gate House runtime ADR. Their doctrine survives in invariants and contracts. |
| ADR-006 | Still meaningful — posture input contract with kings-guard. |
| ADR-007 | Credential separation is doctrine here; materialization implementation belongs to secrets-engine. |
| ADR-009 | Still meaningful — Assistant session binding. |
| ADR-010 | Still meaningful — Autonomous mandate model. |
| ADR-013 | Still meaningful — MCP authorization integration. |
| ADR-014 | Still meaningful — policy self-modification protection. |

Future ADRs in Gate House decide doctrine and responsibility boundaries. They
must not select an Engine's implementation technology or create a Gate House
runtime surface.

## 18. Blueprint summary

Gate House establishes the security doctrine that makes the runtime chain
coherent. It does not join that chain as a service.

```text
agent decides what to attempt
    ↓
engines establish identity and context
    ↓
access-engine decides what may cross
    ↓
secrets-engine materializes bounded authority
    ↓
the perimeter and resource enforce it
    ↓
evidence and adversarial review show whether the doctrine held
```

> **The mandate and operating mode are Gate House's. The decision is
> access-engine's. The credential is secrets-engine's. The perimeter is
> ops-mason's and ops-warden's.**