gate-house/SCOPE.md

# Scope

Derived from `INTENT.md`. Gate House is the council where NetKingdom's security
and defence doctrine is established, documented, taught, and supervised. It is a
**Staff**-layer repository: it holds no runtime position and renders no
authorization decision.

> **The mandate and the 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.**

## In scope

- **doctrine** — estate invariants, operating modes, and the argument behind
  them. The secrets best-practice guide is SecurityCanon `SEC-DSM` 1.0.0, which
  Gate House teaches and does not edit. Doctrine that stabilizes here graduates
  into `net-kingdom/canon/standards/`
- the **authority context schema** — what must be *sayable* about an agentic
  authority request (principal, actor, runtime identity, tenant, environment,
  mandate, task, operating mode), consumed by access-engine as input claims
- **principal / actor / runtime-identity separation** as a model
- **mandates, delegation, attenuation, and authority ceilings** as a model and a
  governance obligation
- the **agentic operating modes** — Assistant and Autonomous as distinct security
  regimes, and the requirements attaching to each
- the **Change Dynamics Envelope** — how much change the organization tolerates,
  expressed so engines and Staff can bound it
- the **posture contract** with King's Guard, including the asymmetry: posture may
  only restrict
- the **MCP and tooling doctrine** — tool availability is not permission
- the **credential-binding contract** stating that credentials are implementation
  artifacts of a grant, materialized by Secrets Engine after authority exists
- **fail-closed semantics** and the restrictive-failure rule, as properties the
  estate must hold
- **conformance review** — whether an actor's authority in practice matches its
  declared mandate and ceiling
- the **assurance specifications** `T-01`…`T-10`, authored here and executed by
  whitehat-security
- the **security curriculum** — what operators, assistants, and autonomous agents
  must understand before they are trusted with authority

Decision types `GRANT` / `DENY` / `REQUIRE_APPROVAL` / `DEFER` are **named** here
and **rendered** by access-engine.

## Out of scope

Gate House holds no runtime position. Not owned here:

- the authorization decision, policy evaluation, or any `/authorize` surface —
  **access-engine** is NetKingdom's only policy decision point
- policy engine selection, policy packages, or policy rollout
- grant storage, credential issuance, leases, or revocation
- human identity lifecycle and memberships — **User Engine**
- tenant and organizational boundaries — **Tenant Engine**
- authentication and federation — **Key Cape**
- credential abstraction and lifecycle orchestration — **Secrets Engine**
- secret storage, PKI, leases, dynamic secret engines — **OpenBao**
- approval storage and lifecycle — **Approval Engine**
- audit custody and evidence retention — **Audit Core**
- operational execution, access lanes, SSH certificates, tunnels, host hardening
  — **Ops Warden**
- construction, reconciliation, recovery — **Ops Mason**
- anomaly detection, behavioral risk inference, security memory — **King's Guard**
- adversarial testing and attack simulation — **Whitehat Security**
- **the workplans of other repositories**

That last one is load-bearing. Work structure belongs to the repository doing the
work. Gate House sets doctrine and reviews conformance; an HQ that starts managing
the estate's chores has become a second decision point wearing management clothes.

Also out of scope: inventing a new policy language, becoming an IAM suite, secret
scanning, SIEM, autonomous remediation, and supporting every agent protocol.

## What would put this repository out of scope

If work here starts producing services, schemas that resolve, or anything
evaluated at request time, it belongs to an engine. A decision point inside Gate
House would put the deterministic authority boundary inside the non-deterministic
management layer, violating `INV-02` — the first invariant this repository
defends. See `decisions/decisions.md` `GH-DEC-2026-001` and
`history/2026-08-28-security-layer-model-and-gate-house-recut.md`.

The `v0.1` milestones `M0`–`M8` and the reference implementation tree
(`api/`, `policy/`, `grants/`, `deploy/`) described the withdrawn authority-plane
design and must not be revived.


## Repository maintenance reuse

The tracked `.generated-work-records.json` adopts the Custodian staged-source
adapter for WORK-RECORDS.md. `make generated-work-records` uses the existing
State Hub renderer through `.generated-work-records.mk`; the shared pre-commit
hook runs this isolated recipe only for opted-in repositories. The corresponding
`make generated-work-records-check` is read-only. Canonical repository identity
is explicit and does not depend on the checkout directory.

Unstaged source changes are preserved; conflicts and unstaged generated-file
changes stop the commit. For `git commit --only`, generate first and include
WORK-RECORDS.md with the selected source paths. Existing generated-only guards
and exact-scope secret scans remain in place. This is repository maintenance,
not a runtime service, authorization decision, deployment or publication.
Other index generators and hub-derived briefs retain their owner boundaries.


## Local orientation brief

`.custodian-brief.md` is a generated local orientation snapshot. It remains on
disk for offline use and is root-ignored rather than versioned. Regenerate it
with the State Hub brief renderer; workplans and other authored repository
records remain authoritative. Brief refreshes must not create Git commits.