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.