Complete GH-WP-0001-T04 authority context contract

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a05e30-2884-71b0-98d7-7edd16ae737b

docs/adr/ADR-001-canonical-authority-context-contract.md

@@ -0,0 +1,83 @@
+# ADR-001 — Canonical authority context contract
+
+**Repository:** gate-house  
+**Status:** accepted  
+**Date:** 2026-09-01  
+**Workplan:** GH-WP-0001-T04
+
+## Context
+
+Gate House owns the vocabulary of an agentic authority request, while
+access-engine is NetKingdom's only policy decision point. The surviving
+`ArchitectureBlueprint.md` material named the required concepts, but left them
+inside an obsolete canonical authorization-request example that also portrayed
+Gate House as an in-path service.
+
+Without a standalone contract, consumers can collapse identity roles, infer an
+operating mode, treat caller-supplied context as verified fact, or implement
+incompatible field meanings. Conversely, prescribing an access-engine API or
+executable policy schema here would recreate the Staff/Engine boundary error
+resolved by GH-DEC-2026-001.
+
+## Decision
+
+Gate House publishes
+[`authority-context.v1`](../contracts/authority-context.md) as a logical claims
+contract.
+
+The contract defines eight claims:
+
+1. principal;
+2. actor;
+3. runtime identity;
+4. tenant;
+5. environment;
+6. mandate;
+7. task;
+8. operating mode.
+
+It defines their meanings, source and binding expectations, mode-specific
+requiredness, fail-closed conditions, evidence obligations, and versioning.
+
+The contract is deliberately not a wire format, token, API, policy package, or
+runtime resolver. Access-engine owns those representations and the
+deterministic interpretation of the context alongside verified identity
+claims, action, resource, approval, posture, and other policy inputs.
+
+No field grants authority by being present. Caller assertion and authoritative
+evidence must remain distinguishable, and security-critical resolution failure
+fails closed.
+
+## Consequences
+
+- Access-engine has a stable semantic target without Gate House taking a
+  runtime position.
+- Identity, tenancy, zone, and mandate sources remain owned by their respective
+  authorities; this contract only says what access-engine must be able to
+  express and bind.
+- Transport-specific schemas may differ, but their mappings must preserve the
+  logical claims and invariants.
+- New authorization-significant claims, modes, or semantic changes require a
+  new contract version and Gate House review.
+- The obsolete Blueprint example remains historical input until GH-WP-0001-T05
+  revises that document; this contract is the current authority-context record.
+
+## Alternatives rejected
+
+### Publish a Gate House `/authorize` schema
+
+Rejected because Gate House is Staff and holds no request-time position.
+Owning an endpoint or executable decision schema here would contradict
+GH-DEC-2026-001 and INV-02.
+
+### Let each consumer infer the vocabulary
+
+Rejected because principal/actor collapse, mode ambiguity, and unverified
+caller context are precisely the semantic failures the doctrine must prevent.
+
+### Put every claim into a credential
+
+Rejected because credentials are implementation artifacts of authorization,
+not the source of authority. The context need only remain linked across the
+authoritative systems and decision evidence.
+

docs/adr/ADR-002-principal-actor-runtime-identity-model.md

@@ -0,0 +1,82 @@
+# ADR-002 — Principal, actor, and runtime identity model
+
+**Repository:** gate-house  
+**Status:** accepted  
+**Date:** 2026-09-01  
+**Workplan:** GH-WP-0001-T04
+
+## Context
+
+Agentic execution introduces at least three identity questions:
+
+- on whose behalf does authority originate;
+- who is directly attempting the action;
+- which concrete workload instance will execute it.
+
+A single `subject`, `user`, or service-account field cannot answer all three.
+Collapsing them permits invisible impersonation, obscures delegation, makes a
+reusable service identity look like a concrete runtime, and prevents evidence
+from showing whether a human, agent, or workload actually acted.
+
+The roles can sometimes resolve to the same underlying subject in a direct,
+non-delegated operation. That does not make the roles synonymous.
+
+## Decision
+
+Principal, actor, and runtime identity are separate semantic roles throughout
+authority input and decision evidence:
+
+- **Principal** is the human, organization, workload, or system on whose behalf
+  authority originates.
+- **Actor** is the entity directly attempting the action and authenticating as
+  itself.
+- **Runtime identity** is the concrete workload instance performing execution.
+
+Implementations must preserve the three roles independently and bind each to
+the appropriate authoritative evidence. They must not fill one missing role by
+copying another, use impersonation to hide the actor, or replace a concrete
+runtime identity with a reusable actor/service name.
+
+In Assistant mode, the active supervising human is principal and the agent is
+actor. In Autonomous mode, the autonomous actor has an independent identity,
+and its principal relationship is established through the organizational
+context and governed mandate. Both modes identify the concrete runtime.
+
+Delegation preserves the originating principal and authenticates the actor as
+itself. Delegated and child authority attenuate; identity linkage never widens
+the authority ceiling.
+
+The roles need not all be embedded in one token. They must remain verifiably
+linked across identity, authorization, credential issuance, execution, and
+decision evidence.
+
+## Consequences
+
+- Policies can distinguish who benefits, who requests, and which workload
+  executes.
+- Assistant actions remain attributable to both the supervising human and the
+  assisting agent.
+- Autonomous actors cannot rely on a borrowed human identity or a shared
+  generic machine identity to erase accountability.
+- Runtime replacement or replay can be evaluated separately from actor
+  identity.
+- Existing transports with one subject field need an explicit mapping or an
+  extension before they can conform to `authority-context.v1`.
+
+## Alternatives rejected
+
+### One canonical subject
+
+Rejected because it erases delegation and cannot represent the agentic chain
+without overloading one identifier.
+
+### Principal and actor only
+
+Rejected because a stable actor identity does not identify the concrete
+workload instance that executed a particular action.
+
+### Treat runtime identity as audit-only metadata
+
+Rejected because runtime identity can be security-relevant policy input and
+must be bound before a positive decision when policy depends on it.
+Reconstructing it after execution is too late to enforce the boundary.