coulomb/gate-house
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Draft GH-DEC-2026-026 on decision classes C0-C3 and the C2 floor; propose GH-WP-0005.

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 5502@bnt-lap001
Assistant-Session: 68b3b02f-5d0f-4e71-8421-796f62e50196
This commit is contained in:
tegwick 2026-10-31 23:02:26 +01:00
parent 8698f50706
commit a3d68c8ba1
3 changed files with 334 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

7
WORK-RECORDS.md
View file

@ -13,6 +13,7 @@
| workplan | GH-WP-0002 | finished | — | workplans/GH-WP-0002-approval-evidence-integrity.md |
| workplan | GH-WP-0003 | finished | — | workplans/GH-WP-0003-statute-v08-amendment-set.md |
| workplan | GH-WP-0004 | active | — | workplans/GH-WP-0004-section-11-layer-declarations.md |
| workplan | GH-WP-0005 | proposed | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-ADHOC-2026-10-03-T01 | done | — | workplans/ADHOC-2026-10-03.md |
| task | GH-WP-ADHOC-2026-10-03-T02 | done | — | workplans/ADHOC-2026-10-03.md |
| task | GH-WP-0001-T01 | done | — | workplans/GH-WP-0001-foundation.md |
@ -48,6 +49,12 @@
| task | GH-WP-0004-T10 | done | — | workplans/GH-WP-0004-section-11-layer-declarations.md |
| task | GH-WP-0004-T11 | done | — | workplans/GH-WP-0004-section-11-layer-declarations.md |
| task | GH-WP-0004-T12 | done | — | workplans/GH-WP-0004-section-11-layer-declarations.md |
| task | GH-WP-0005-T01 | todo | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-0005-T02 | todo | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-0005-T03 | todo | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-0005-T04 | todo | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-0005-T05 | wait | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| task | GH-WP-0005-T06 | wait | — | workplans/GH-WP-0005-decision-classes-doctrine.md |
| intake | GH-IN-0001 | closed | red | intakes/intakes.md |
| intake | GH-IN-0002 | closed | red | intakes/intakes.md |
| intake | GH-IN-0003 | closed | red | intakes/intakes.md |

219
decisions/drafts/GH-DEC-2026-026-decision-classes.md Normal file
View file

@ -0,0 +1,219 @@
## GH-DEC-2026-026 — Decision classes C0–C3: ceremony is proportionate to reliance, and a decision relied on as authority for an act is at least C2
**Draft, status `proposed`. Not registered in State Hub.** The metadata below is
fenced as `text` on purpose: a `yaml` block carrying a `GH-DEC-` id is
registered as a hub decision by the consistency sync (C-32), and this record
is not ruled yet. When the founder rules, move it into `decisions/decisions.md`
with the usual `yaml` block and let the sync register it.
```text
id: GH-DEC-2026-026
kind: decision
title: Decision classes C0-C3; ceremony is proportionate to reliance, and a decision
relied on as authority for an act is at least C2
status: proposed
owner: Bernd Worsch
repo: gate-house
standard: net-kingdom/canon/standards/security-layer-model_v0.8.md
source_note: net-kingdom docs/proposals/2026-10-31-decision-services-alignment-review.md
(net-kingdom@b764561, sections 4.3, 4.4, 6.1, slice S5); net-kingdom
docs/proposals/2026-10-31-nk56-t17-founder-approval-path.md; hub message
8f4ba4e2-5cb4-4965-9c5e-5aedf8fb6b5f (2026-10-31); founder direction 2026-10-31
(decision handling proportionate: easy for simple, complete for complex)
requested_dispositions: [approved, revised, rejected]
affects: [gate-house, informed-decision, approval-engine, state-hub, net-kingdom,
access-engine, audit-core, ops-mason, railiance-platform]
created: '2026-10-31'
```
## Question
The founder asked (review §6.1) whether four decision classes — **C0 note**,
**C1 confirm**, **C2 bound approval**, **C3 instrument** — and the rule
*"anything a service will execute on the strength of the decision is C2"* are
the right cut. `GH-DEC-2026-016` §5 left open which acts require human approval
at all and said that is Gate House's doctrine. This record answers that open
point as a floor rule, and sets how much ceremony each class carries.
## Position in one paragraph
**The cut is right, with one change to the rule.** The trigger is not *who
executes* but *what is relied on*: a decision is at least C2 when anything —
service, executor, PEP, agent or pipeline — relies on it as the authority for
an act that the relying actor's standing mandate does not already grant. That
is the review's rule made precise. It catches agents as well as services, and
it does not pull direction-setting decisions (a workplan, a choice of option)
into C2 merely because work follows them. Three guards make the cheap classes
safe: C1 evidence is never authority, the class floor comes from the act and
not from the requester, and every modifier — `risk_class`, posture — may only
raise.
## Ruling 1 — Four classes, distinguished by what may rely on the result
| | **C0 note** | **C1 confirm** | **C2 bound approval** | **C3 instrument** |
| --- | --- | --- | --- | --- |
| What it is | A record. No human disposition is claimed | A human disposition on a question. Sets direction; authorizes no act by itself | A human disposition bound to one exact act, which an actor will rely on | A multi-party or contractual commitment |
| May be relied on as authority for an act | No | **No** | Yes — for the bound act only, once, within its validity | Reserved |
| Surface | State Hub only | informed-decision single-screen confirm: question, the packet item(s) it rests on, at least one required highlight, the options | informed-decision full memo presenting an approval the actor created (review §4.2) | Not yet defined (informed-decision L4 direction) |
| Assurance | None | Authenticated human session, fresh at answer (the surface states its freshness bound) | `aal2`, fresh at answer | Per party; not yet defined |
| approval-engine object | No | No | Yes: created by the actor who will rely on it, `human_control: true` declared at issue (`GH-DEC-2026-016` §3) | Per party; not yet defined |
| Evidence | The hub record | informed-decision presentation (`view_hash`) and disposition, the authenticated subject, audit-core emission; resolves the hub decision by write-back | All of C1, plus the approval entry bound to the binding digest; the approval id joins the hub decision | Not yet defined |
| Who may decide | Anyone, including agents; nothing is decided | A human principal holding the decision scope (the founder for estate scope). Directory-asserted humanity only (`GH-DEC-2026-016` §5) | The human approvers listed for the action class, each a human principal, none of them the actor | Not yet defined |
Notes on the table:
- **C0 is not a lesser decision; it is not a decision.** A record that claims a
human answered something is at least C1. A hub item flagged `needs_human` is
never resolvable at C0.
- **"Who may decide" never includes an agent at C1 or above.** An owner agent's
review, assent or "delegated technical owner review" is input to a decision
and is labelled as such. It is not approval at any class. (Cognition proposes.)
- **C3 is reserved, not usable.** Until a C3 record rules it, a multi-party or
contractual commitment is not taken through this facility at all. It is not
quietly posed as C2 with extra approvers, because per-party assurance and
counter-signature are what C3 would add.
## Ruling 2 — The floor: relied-on means bound
**A decision MUST be at least C2 if any actor will rely on it as the authority
for an act that the actor's standing mandate does not already grant.** "Rely"
means the decision, or a record of it, is checked — by code or by an agent's
reading — as the reason an act is permitted. Typical acts: a privileged or
bounded execution run, a credential issue or rotation, a production deploy or
`kubectl apply`, an access-engine policy or pin change, any widening of an
authority ceiling.
Corollaries, each normative:
1. **C1 evidence is never authority.** No PEP, executor, lane or agent may
accept a C1 disposition, a hub resolution, or text in a workplan, CCR or
commit message as the approval of an act. If an act later needs a decision
that was taken at C1, the act is posed again at C2. C1 evidence is never
promoted.
2. **Direction does not carry authority downstream.** Approving a workplan or
choosing option A is C1. Each act inside that work that needs authority
carries its own C2 approval, or is run by the human principal personally (the
founder-run lane). The C1 decision is context for those acts, not their
permission.
3. **The founder running an act personally is not a delegation.** Where the
human principal is the one who executes, with their own authentication on
the lane, no approval object is needed, because nothing relies on someone
else's decision. The decision to do it may be C0 or C1. This is the existing
"live changes: founder runs" pattern, and it stays.
4. **Within the actor's standing mandate, no class is required.** An agent
editing its own repository within its mandate needs no approval. A decision
about *what* it should do (a workplan) is C1 at most.
5. **The test is applied to the act, not to the requester's choice.** Each
action class has a minimum class, set by doctrine (the examples in Ruling 4
are the first table). A requester may pose higher than the floor and never
lower. A presenting surface that is asked to present an act below its floor
refuses. An act whose class cannot be determined is treated as C2
(fail closed).
## Ruling 3 — Modifiers may only raise
`risk_class`, posture from King's Guard and any other adaptive input are
**restriction-only**, the same asymmetry as Blueprint §8 ("posture may only
restrict"):
- **Within C2** they may add required highlights, add required approvers (dual
control), shorten validity, require a fresh step-up, or narrow the bound
scope. They may not lower the class, drop `human_control`, relax `aal2`,
remove a listed approver or lengthen validity beyond the action class's
ceiling.
- **Within C1** they may add highlights, or raise the decision to C2.
- **Nothing lowers a class.** No `risk_class: low` turns an executed act into a
C1 confirm. A low-risk executed act gets a *lighter C2 memo* (fewer
highlights), not a different class. That is where "easy for simple cases"
lives inside C2.
## Ruling 4 — The estate's current cases
| Case | Class | Why | Today |
| --- | --- | --- | --- |
| Bounded Execution Admission (NK-WP-0056) | **C2** | The executor relies on it to run; the approval is created by `service:nk-bind-executor`, presented via informed-decision (review §4.2), approved at `aal2` | No path yet (NK-WP-0056-T17); review slices S1, S2 |
| Admission with high `risk_class` | **C2**, raised | Added highlights (scope ceiling, revert) and, where the action class says so, a second human approver | — |
| CCR credential lane (platform-owner and net-kingdom-owner approvals) | **C2** | The lane issues or rotates a credential on the strength of it; each required owner approval is a human entry on one approval object | Recorded as agent-written YAML comments; the second approval for CCR-2026-0058 was entered by hand. Not C2 evidence |
| Production deploy / `kubectl apply` by an agent or pipeline | **C2** | Executed on the decision | ops-mason's founder plan approval (`GH-DEC-2026-022`) sits at this floor. Its accepted §6.4 exception is not changed here, but the approval carrying it is C2 by this record |
| access-engine policy or pin change, any authority-ceiling change | **C2** | Executed by a pipeline; agents cannot edit their own ceiling | — |
| Founder runs a live step personally | none required (C0 or C1 for the decision) | Corollary 3 | The existing founder-run lanes |
| Workplan approval (`proposed` → `ready`/`active`) | **C1** | Direction; acts inside it carry their own C2 or are founder-run | "Approved by the founder in session" written by an agent: asserted, not evidenced |
| Adopting an owner proposal or doctrine record (including a GH-DEC ruling) | **C1** | Sets doctrine or direction; nothing executes on it | GH-DEC records cite founder in session; `GH-DEC-2026-025` already went through a full memo, which is allowed (higher than the floor) |
| Choosing between options A/B | **C1** | Direction; if the chosen option is then executed, that execution carries its own C2 | — |
| Acknowledging a report, recording a finding, coordination notes | **C0** | Nothing is decided | Hub records |
## Ruling 5 — The hub indexes; evidence resolves
Endorsed from review §4.4, as doctrine:
- A State Hub decision that needs C1 or C2 **MUST be resolved by the evidence**
(informed-decision write-back carrying the authenticated subject, memo
revision and `view_hash`, and for C2 the approval id), **never by an agent's
free text**. `decided_by` written by an agent is asserted provenance and stays
visibly asserted (ASM-M04, `GH-DEC-2026-023` C6).
- The hub record is the index of what is waiting. It is not evidence and holds
no binding.
## Ruling 6 — The present-existing contract is consistent with doctrine
The review's §4.2 contract (the actor creates, informed-decision presents and
adds the human entry, the actor consumes) is the shape doctrine asks for, and
nothing in Gate House required informed-decision to be the creator:
- Posing needs no human act (`GH-DEC-2026-023` Ruling 1). The actor creating
its own request is proposing.
- The human requirement attaches to the bind (`GH-DEC-2026-016`), and
`human_control: true` is declared at create by the actor.
- The surface's live read of the approval and the identity compare of
approval id and binding digest are the validation (`GH-DEC-2026-023` C1).
The surface must not accept the actor's memo as a statement of what the
approval binds.
- **The actor MUST NOT be an approver of its own approval.** approval-engine
already refuses non-human approvers under `human_control`, which covers a
service actor. This line covers a human actor too.
Owners decide the mechanics: informed-decision (profile or route), approval-engine
(`presentation_ref`, `aal2` floor, `actor_consumes`), State Hub (link columns).
## Build-mode relaxations this record names
Under the standing build-mode directive (2026-10-03) these are recorded for the
close-down list, not waived:
- **B1.** `aal2` is stored but not enforced by approval-engine
(APPROVAL-WP-0007-T01). Until it is, the C2 assurance is checked by the
surface and the executor. Re-arm: the object refuses an entry below the
class's assurance.
- **B2.** Consume does not check consumer = actor (APPROVAL-WP-0007-T02). Re-arm
as written there.
- **B3.** C1 does not exist as a surface yet (review slice S4) and hub write-back
is off (S3). Until both land, C1 decisions are taken in session and recorded
as **asserted** (`decided_by` names the founder, the record says "asserted in
session"). They are not C1 evidence, and corollary 1 already forbids relying
on them.
- **B4.** CCR approvals recorded as YAML comments are below the C2 floor. Until
the lanes move to approval objects, every CCR approval stays an asserted record
and the close-down list carries it.
Recording these in the-custodian close-down checklist is the-custodian's act;
this record asks for it and does not edit that file.
## What this does not rule
- The mechanics of any service (profile vs route, column vs `evidence_ref`,
validity defaults). Those belong to their owners.
- The list of action classes beyond Ruling 4's first table, or which classes
require dual control. Each new action class is assigned its floor by a Gate
House record or by the owning standard (e.g. the BEA standard), never by the
requester.
- C3. Reserved for a later record.
- Break-glass. It keeps its own path and is not a decision class.
## Reversal condition
Ruling 2 reverses if a case is found where relying on a C1 disposition for an act
is necessary and safe. That would show the floor was drawn at the wrong act, and
the repair is the action-class table, not a lower class. Ruling 1's C1 tier
lapses if the C1 surface is not built and C1 decisions remain asserted text
through the production close-down. The estate would then have three classes,
and C1 should be removed rather than left as a name for free text.

108
workplans/GH-WP-0005-decision-classes-doctrine.md Normal file
View file

@ -0,0 +1,108 @@
---
id: GH-WP-0005
type: workplan
title: "Decision classes C0–C3 — doctrine ruling and estate handoff"
domain: infotech
repo: gate-house
status: proposed
flavor: implementation
origin: net-kingdom docs/proposals/2026-10-31-decision-services-alignment-review.md (S5); hub message 8f4ba4e2-5cb4-4965-9c5e-5aedf8fb6b5f
owner: gate-house
topic_slug: infotech
created: "2026-10-31"
updated: "2026-10-31"
---
# Decision classes C0–C3 — doctrine ruling and estate handoff
## Goal
Get a founder ruling on the decision classes and the C2 floor drafted at
`decisions/drafts/GH-DEC-2026-026-decision-classes.md`. Then hand the ruled
doctrine to the owners who implement it. Gate House sets the classes, their
ceremony and who may approve. It does not manage the owners' work
(SCOPE: "the workplans of other repositories" are out of scope).
## Why now
NK-WP-0056's bounded executor has no approval path (NK-WP-0056-T17), and the
founder asked for decision handling to be proportionate: easy for simple cases,
complete for complex ones. Routine founder decisions are recorded as free text
today because the only bound path is too heavy for them. Every class assignment
in review slices S1–S6 waits on this doctrine.
## Tasks
### T01 — Founder ruling on GH-DEC-2026-026
Present the draft for a disposition (approved / revised / rejected). Open
points for the founder: the reliance trigger replacing "a service executes"
(Ruling 2), C3 reserved rather than usable, and the actor-not-approver line
(Ruling 6).
```task
id: GH-WP-0005-T01
status: todo
priority: high
```
### T02 — Record the ruling
Move the record into `decisions/decisions.md` with a `yaml` metadata block,
status `resolved`, and the founder's rationale. Let the consistency sync
register it. If the ruling is revised, revise the draft first.
```task
id: GH-WP-0005-T02
status: todo
priority: high
```
### T03 — Hand the ruled classes to the owners
Send one message each to informed-decision (C1 surface, present-existing,
class floor refusal), approval-engine (aal2 floor, actor_consumes,
actor-not-approver), state-hub (resolution by evidence only), and net-kingdom
(BEA and CCR action-class floors). Each owner accepts, changes or declines in
its own repository.
```task
id: GH-WP-0005-T03
status: todo
priority: medium
```
### T04 — Ask for the build-mode relaxations B1–B4 on the close-down list
Ask the-custodian to carry B1–B4 in `docs/security-close-down-checklist.md`.
Gate House does not edit that file.
```task
id: GH-WP-0005-T04
status: todo
priority: medium
```
### T05 — Graduate the doctrine to net-kingdom canon
Once the slices have exercised it, draft the class table and the floor rule as
a section for the net-kingdom canon standard and send it to that standard's
owner for review.
```task
id: GH-WP-0005-T05
status: wait
priority: low
```
### T06 — Conformance review after first use
After the first C2 admission and the first C1 confirm go through
informed-decision, review them against the record. Check that no C1 evidence
was relied on as authority and that no class was lowered.
```task
id: GH-WP-0005-T06
status: wait
priority: low
```