Commit graph

45 commits

Author SHA1 Message Date
1a12223574 Create private evidence directories safely on fsGroup volumes
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-11 12:41:04 +02:00
bda9381f07 Package protected review runtime and prepare deployment admission
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-11 01:21:37 +02:00
bb5b607bbd docs(T07): correct the premise -- key-cape is not waiting
T07's note and the registration doc said publishing would close
KEY-WP-0013-T02, blocked since 2026-09-08. Checked against key-cape: T02 is
done, T05 (which actually held the human registration) is done, and key-cape
closed KEY-WP-0030, a follow-up this repo prompted. The issuer side of the gap
that created this repository is already discharged.

Submitting the registration closes INFD-WP-0001-T07, not a key-cape task.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
2026-09-11 00:53:13 +02:00
83849b75d4 Connect policy-gated browser review and audit runtime
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-11 00:31:03 +02:00
2cc32168ac Persist review evidence and deliver audit records transactionally
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-10 23:27:19 +02:00
0e48355b9f Add verified browser login and human approval HTTP client
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc
2026-09-10 22:05:17 +02:00
4e103f62a0 Activate nesting per GH-DEC-2026-015: view_hash carries binding.digest
approval-engine met the condition. Verified here rather than taken on report:
their docs/approval-claim.md carries "Presentation exclusion — GH-DEC-2026-015
§4" in normative language, and I ran
tests/test_claim_contract.py::test_presentation_changes_cannot_change_the_approved_act
myself — 1 passed. That test pins the digest input set from BOTH sides, and the
narrowing half is what makes it real: without it a digest over four fields, or
over a constant, would pass the widening half perfectly.

view_hash now carries binding.digest and the act-scope is no longer
independently canonicalized here, so the act has exactly one canonicalization
computed by the layer that owns it. approval_binding_digest is validated for
shape and refused without its approval id — it is carried, never computed.

The three published vectors are unchanged: they do not carry the new key, so
pick omits it. Asserted, not assumed.

The cycle condition did not disappear, its protection moved — from refusing
nesting to approval-engine's normative exclusion. layer.yaml carries it as
cycle_condition with a test, so a future widening meets a rule rather than
silence.

One thing not assumed. Both gate-house and approval-engine said our binding
slice canonicalizes principal and target, two of their five fields. target
plainly is act material and is now dropped. But their principal is the party ON
WHOSE BEHALF the approval was issued, while ours is the person being BOUND — the
approver. Different roles, and dropping ours would remove who was shown this
from view_hash and gut the promise. Kept it, declared principal_role_overlap
open in layer.yaml, tested that changing the approver still moves view_hash, and
raised it rather than silently resolving it either way.

L0/L2 are unaffected: with no approval there is no digest to defer to, and
test_act_scope_still_binds_when_there_is_no_carried_digest pins that.

100 tests pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:58:22 +02:00
d0302e1046 Add .gitignore; untrack committed bytecode
__pycache__ was committed alongside the domain core. Untracked and ignored.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:39:31 +02:00
d81b6f5c90 Sync work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:38:53 +02:00
custodian-sync
a67f086687 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-10:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:38:47 +02:00
9e1f77e32b Build the T08 domain core with the engine behind a seam
approval-engine APPROVAL-WP-0002-T01 is still progress and its namespace has no
pods, so the live end-to-end proof cannot run. Built everything that does not
depend on it, with the engine behind a Protocol plus a fake carrying its real
refusal semantics, so its arrival is a wiring change rather than a build.

- memo.py: the Decision Memo, versions, binding document. Principal, Scope,
  Awareness and Hat are dataclasses rather than dicts because the canonicalizer
  requires a shape and a missing key should fail at construction rather than
  deep inside hashing — which is exactly how it failed twice while building
  this. Field names follow the governed canonicalizer (item_id, severity,
  locator): the published vectors are the contract, so the object was aligned to
  them rather than the reverse.
- presentation.py: the sole writer of view_hash. One writer, one canonicalizer,
  one place to audit. Acknowledgment is an explicit method call and nothing
  infers it from scroll, dwell or focus.
- disposition.py: verbs and guards G_NOAGENT, G_STEP, G_PRES, G_ACK, G_REASONS,
  G_SEALED. accept is ABSENT from weak steps rather than present-and-disabled,
  because a greyed-out accept still teaches the wrong model. Only accept reaches
  the engine; a memo return is not represented there at all.
- provenance.py: claim routes per A-16. assert_human_control_dischargeable
  refuses a registration-supplied human, so PR-11's limitation fires at the
  point of use instead of sitting in a document.
- evidence.py: local outbox, commitment-only records carrying the
  GH-DEC-2026-014 §4 existence assertion, per-class reconciliation counts, and a
  custody-locator guard that rejects credentialed URLs (PR-12).
- approval_client.py: 409 duplicate_approver is success, 409 conflict terminal,
  503 fail-closed, approval:consume refused before a token is requested.

87 tests pass, including every negative case in the Use Case Catalog and that a
fail-closed outcome is recorded as a stance application with no verb field —
never as a decline, because the human did not make one.

T08 stays progress: the live proof is the remainder.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:38:20 +02:00
4379576abd Sync work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:30:29 +02:00
custodian-sync
5c1859cba0 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-10:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:30:22 +02:00
e4acfa39ed Close T07: client registration submitted to key-cape
The two strings approval-engine asked for on 2026-09-08 are submitted:
client_id informed-decision-approver, redirect
https://decisions.coulomb.social/auth/callback. This discharges the gap that
created this repository.

The submission declares the tenant provenance rather than letting it read as a
directory fact, and raises PR-11 back to key-cape: principal_type: human is a
property of the client registration, structurally the same shape as the
gap-route tenant, so GH-DEC-2026-016 §5 now depends on that claim in a way it
did not last week.

heartbeat_classes sent to audit-core — three classes at 86400, including
presentation with the reasoning for declaring one on a class their guidance put
outside it, offered for them to overrule.

The GH-DEC-2026-015 activation condition relayed to approval-engine: state the
five-field set as normative and add a test that fails if the digest input set
changes. Their reasoning exists in substance already; what is missing is that a
contributor can make that change today with nothing stopping them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 20:29:54 +02:00
e5da42e888 Sync work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 19:20:13 +02:00
1fb17aec6b Apply GH-DEC-2026-015/016 and the audit-core registration; both blockers cleared
Origin and evidence path both landed today.

T07 origin: railiance-apps deployed decisions.coulomb.social and corrected the
hostname in this repo — not the decide.coulomb.social this workplan proposed.
Verified here rather than taken on report: both paths 200, TLS verify 0, Let's
Encrypt cert valid to 2026-12-09.

T08: audit-core registered the source with every field as proposed and landed
the detection half. INFD-IN-0003 closed. Their refinements booked — reconciliation
on the high-volume class too, since rate detects a stream stopping but never a
stream missing the particular renders that mattered, which is exactly our threat
model; and PR-12, the custody locator must be a stable non-secret identifier
because redact scans data and an existence declaration arriving without its
pointer looks complete while being useless.

INFD-IN-0004 ruled as GH-DEC-2026-015: gate-house reversed itself and nesting is
permitted for this pair. The decisive ground was not the cycle argument we led
with — our binding slice canonicalizes principal and target, two of the five
digest fields, so co-reference left us performing a partial recomputation of one
act in a second vocabulary, closer to the translation R3 forbade than nesting
is. Our ordering objection was withdrawn as mistaken.

The permission is conditioned and NOT ACTIVE until approval-engine states its
presentation exclusion as normative and tested. layer.yaml is deliberately
unchanged and carries nesting_permission_active false — we do not activate on
our own initiative.

GH-DEC-2026-016 ruled NC-03. Its §5 is live rather than hypothetical and is
booked as PR-11: principal_type: human is a property of the client registration,
structurally the same shape as the gap-route tenant, so a human-in-the-loop
control must not be discharged on it as verified humanity.

T07 stays progress: the submission to key-cape is written but unsent, blocked by
the local permission classifier rather than by any repository.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 19:19:10 +02:00
1614f257b6 docs(T07): origin is live; registration ready to submit
decisions.coulomb.social answers 200 over an issued Let's Encrypt certificate as
of 2026-09-10 14:32 UTC. The condition this document set for its own submission
— a real origin rather than a plausible one — is met.

T07 stays progress: the remaining acceptance criteria are that the contract
actually reaches key-cape and that a token issued against the registration is
accepted by approval-engine's verifier, which cannot be shown until
approval-engine is deployed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
2026-09-10 16:34:38 +02:00
4d33a59f5b docs(T07): settle the approver origin as decisions.coulomb.social
The operator assigned decisions.coulomb.social, not the decide.coulomb.social
this workplan proposed. Redirect URIs match byte-exactly at /authorize, so the
proposal is corrected in place rather than reconciled after submission — a
one-character miss presents as a rejected approval, not as a registration
defect.

DNS resolves. The Ingress and certificate are written in railiance-apps
(manifests/informed-decision-ingress.yaml, dry-run clean) but not applied, so
T07 stays progress: DNS alone is not an origin, and a host that does not answer
over TLS fails the same way a wrong hostname does, only later.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
2026-09-10 16:17:52 +02:00
0838bf81fa Sync intake ids and work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 14:01:57 +02:00
3a7391fe63 Raise INFD-IN-0004: approval-engine's R3 answer conflicts with the ruling
approval-engine answered R3 and recommends exactly the option GH-DEC-2026-012
refused: that our binding document carry their binding.digest as a field rather
than re-canonicalize action/actor/principal/purpose/target ourselves. We cannot
comply with both, so this is raised as a finding rather than resolved.

It is not a wording difference. Our binding slice canonicalizes principal and
target, two of the five fields in their digest, so co-reference by identifier
alone leaves two independent canonicalizations of one act linked by a shared id.
GH-DEC-2026-012 manages that with an authority rule; approval-engine's proposal
removes it. Both are coherent and they are not the same design.

New information the refusal may not have had: their digest covers exactly five
act fields, and they state that widening it to cover presentation would be a
defect since a new UI release would invalidate every prior approval. The
GH-DEC-2026-008 cycle condition is mutual containment, so if their digest
structurally cannot contain view_hash the containment is one-directional. Not
asserted as settling it — that cycle was found by two engines independently
within hours, and "the cycle cannot arise here" is the belief such failures
punish.

Deliberately not adopted, despite coming from the layer that owns the digest and
despite our having offered to let them settle R3. Gate House was right that a
bilateral agreement produces agreement rather than an authority rule, and that
applies to this one too. layer.yaml is unchanged and carries a
linkage_under_review marker rather than a silent edit.

Also carries the smaller doctrine question approval-engine handed on: whether
approver evidence should be human-only at the engine, since
entries[].principal_type is auditable after the fact and stops nothing, and
there is no upstream backstop for humans-bind-agents-draft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 13:59:52 +02:00
242168d5fb Sync work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 08:08:00 +02:00
custodian-sync
a2cabfaa97 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-10:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 08:06:58 +02:00
50367d0d78 Write the key-cape client registration contract (T07 progress)
Everything except the host is now fixed: client_id informed-decision-approver,
callback path /auth/callback, authorization-code + S256 PKCE public client,
scopes [openid, approval:read, approval:approve], the expected token shape, and
the assurance shape cited from key-cape's contract rather than restated so it
cannot drift.

Section 5 declares the tenant provenance rather than assuming it. Nothing
populates domain.User.Tenant for approver users, so declaring tenant:platform
reaches the token by the gap route by construction rather than by accident.
GH-DEC-2026-013 was explicit that a tenant the directory does not carry must not
be declared unless we are prepared to say so in the record — so it is said,
with the two consequences: the claim is stored with its provenance, and it is
never used as the act-scope.

Deliberately NOT submitted. The origin needs a DNS A record, an Ingress manifest
and a certificate, which is work in railiance-apps rather than here.
decide.coulomb.social is proposed and consistent with the estate's existing
Traefik/TLS-per-host pattern, but proposing a plausible hostname is not the same
as owning one, and submitting a redirect for a host that does not resolve is the
exact failure approval-engine avoided by refusing to invent these strings.

T07 stays progress with the deployment dependency named and owned elsewhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 08:06:10 +02:00
7e7ad0293c Sync work records
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 08:04:53 +02:00
5c33d17330 Apply GH-DEC-2026-013 and GH-DEC-2026-014; close INFD-IN-0002
Two rulings landed and both corrected something.

GH-DEC-2026-013 accepted our binding-versus-awareness argument, wrote it into
the record as its §6, and did not change the outcome — it sharpened the defect.
Two different facts share one field named tenant: the act-scope, a property of
the act that our binding slice commits, and the principal's membership, a
property of the person that approval-engine exact-matches. Gate House's
correction stands: a binding slice that must commit the scope being entered
should commit that scope, not borrow a membership claim to stand in for it. Our
schema already does — binding.target IS the act-scope and is inside view_hash —
so no field was added, only a statement (PR-08) and a provenance record (PR-09),
since key-cape emits tenant as a bare string.

key-cape had already implemented registration-bound tenancy on 2026-09-09,
correct under both candidate rulings, so the fail-closed-at-first-use risk that
made us withhold the client strings was already retired. IN-0002 closed. The one
remaining input to T07 is the deployed origin.

GH-DEC-2026-014 granted commitment-only evidence and bounded it. It satisfies
non-alteration and NOT reconstructability, and must not be described otherwise
anywhere. It also corrected our wording of the gap: we wrote that it leaves us
able to erase the content, which understates it. Commitment-only moves integrity
out of our control and leaves availability entirely inside it — the party that
can withhold the content is the party the evidence is about. Limit 3's condition
reduced, not removed.

The grant carries a condition we did not propose and would not have thought of:
the path must assert that committed content exists and where custody sits, so
non-production is a finding attributable to the custodian rather than an
unremarkable blank. A commitment with no assertion that something is being
committed to is indistinguishable from a commitment to nothing. Booked as PR-53,
and marked not-a-reversal-candidate.

Recorded the meta-rule Gate House named, now in its third setting here: unknown
versus absent in the stance map, directory-asserted versus registration-supplied
in the tenant claim, erased versus never held in the evidence path. Wherever a
system reaches one appearance by two routes, the record must say which route.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-10 07:57:57 +02:00
8b8a5cd6ef Sync intake ids and work records
fix-consistency registered INFD-IN-0002 and INFD-IN-0003 in the hub and wrote
their ids back into intakes.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 23:25:28 +02:00
024946e9da Close INFD-IN-0001; design the independent evidence path; track both blockers
Housekeeping the ruling left behind, plus the one piece of blocked work that was
substantially ours to move.

INFD-IN-0001 closed with its resolution recorded, matching approval-engine's
IN-0002 form. It was still open after GH-DEC-2026-012 answered it.

INFD-IN-0003 and docs/evidence-path-design.md take up O-02, which was sitting in
the blueprint as "mechanism unchosen". Read independence and the local
transactional outbox are settled and not in question. The real question is what
travels, and it is sharper for us than for approval-engine because a
presentation record carries the brief and packet material actually shown to a
human. Three candidates with costs; proposal is commitment-only for Stage 1 —
hashes, principal, timestamps, acks, co-referenced approval id — which
discharges limit 3 and removes our ability to alter the record, while leaving us
able to erase the content. That residual is declared alongside the existing
compromised-surface one rather than papered over.

Deliberately not proposing the full binding document unilaterally: it would put
commercial and personal material into the audit fabric under retention and
export entitlements designed for audit events. That is a meaningful change in
what audit-core holds and is its owner's to accept, not ours to assume. The
third option, a separate evidence store, is refused here because that store has
no owner and inventing one routes around the §16 decision against stronger
archival custody.

Cadence declared and its form argued rather than copied: approval-engine's
heartbeat answer suits genuinely low-volume classes, but ours are mixed —
presentations are one per render, while dispositions and stance applications are
low-volume and are the security-relevant ones. Reconciliation per class as
primary, heartbeat for the low-volume classes. Depends on AUDIT-WP-0009 T04/T06;
declared, not claimed operating.

INFD-IN-0002 files the tenant blocker as a tracked record rather than leaving it
in message threads and a blueprint footnote. T07 and T08 now name their blocking
intakes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 23:19:27 +02:00
custodian-sync
d50f480075 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-09:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 22:29:41 +02:00
b8e57e8404 Architecture Blueprint and rewritten SCOPE; close T05 and T06
T05 written after the ruling rather than before it, which was the point of
gating it. GH-DEC-2026-012 limit 3 did most of the shaping: the evidence copy
must reach audit-core independently of this component, because here the actor
being audited and the evidence source are the same. Booked as four binding
implementation consequences plus O-02, which must be resolved before T08 ships —
"we will add the independent path later" is how limit 3 becomes
limit-3-in-principle.

Other constraints fixed in the blueprint: presentation/ is the only writer of
view_hash; the approval-engine client exposes no validity cache; a fail-closed
outcome is never recorded as an approver's decline, since the human made none;
the assurance shape is cited from key-cape's contract rather than restated so it
cannot drift; and no polling loop may synthesise the inbox approval-engine
refuses to provide.

T06 closed with the SCOPE.md rewrite the ruling unblocked. It carries a "What
this repository does not claim" section, because a scope file listing only
capabilities overstates them: the decision path is not validated while
GH-DEC-2026-010 is open, the residual is not closed, view_hash is not inside the
approval entry, and nothing is deployed.

Two open items block the remainder. O-01, the human token tenant, blocks T07 and
is not ours alone to decide. O-02, the independent evidence path, blocks T08.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 22:29:06 +02:00
custodian-sync
be74a6bc35 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-09:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 22:26:06 +02:00
f6376ddff5 Declare the layer per GH-DEC-2026-012; close T02
Gate House ruled all three questions within a day, attributing the speed to the
request being filed before the architecture with candidate answers and their
costs.

R1 PEP-shaped, confirmed as proposed. The ruling settles the shape; the layer
stays ours to declare, so layer.yaml is written in this repository's voice
rather than transcribed from the reply.

R2 yes to a presentation claim, no second catalog row, under three limits now
declared in layer.yaml and tested. Limit 2 — the claim must never be an input to
the decision it presents for — is load-bearing: our self-dealing argument was
accepted because it holds, not despite it. Limit 3 drives architecture, since
here the actor being audited and the evidence source are the same component.

R3 (b) with the authority rule: binding digest authoritative for what the
request is, view_hash only for what was shown, neither substitutable, and a
disagreement between them is a finding against the presenting surface rather
than a fact about the request. Linkage is co-reference; nesting was refused
because it reproduces the GH-DEC-2026-008 hash cycle.

Built to v0.8 obligation 3 rather than migrating later: axis enumerated, unknown
resolves to fail_closed, absent distinguishable from unknown in the record, and
published-equals-shipped asserted by test rather than claimed. Every stance is
fail_closed, which is a conclusion not a shortcut — ops-warden can justify
fail_open on a continuity argument that does not exist here.

GH-DEC-2026-010 inherited as a declared gap in four documents: a decision cannot
today be proven to have come from access-engine. The decision path must not be
described as validated while FLEX-WP-0024 is open.

46 tests pass. T05 and T07 unblocked.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 22:25:35 +02:00
f36e2b789a Amend GOAL DoD-3 to the correlation triple; record the approval-engine exchange
Makes true what was already told to approval-engine: DoD-3 read
"reconstructable from a view_hash", which assumed the hash could ride into the
approval entry. It cannot — POST /entries discards its request body by design so
that record holds no caller-supplied data. Adopted their arrangement rather than
asking for a field, and recorded the consequence honestly: an auditor holding
only the approval object cannot reach the presentation without this surface's
record or audit-core.

Two invariants added to GOAL: approved is never rendered as permission to act,
and entitlement to view is access-engine's — a 200 from approval-engine is not
permission to see the approval.

T02 notes record that approval-engine found two real defects in the T03/T04
drafts, that their open questions A and B are now with key-cape because both
change an implemented registration, and that R3 remains open with an offer to
withdraw it if approval-engine considers it settled by its claim contract.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:22:06 +02:00
08b190928f Revise specs against approval-engine's approver-surface requirements
approval-engine replied to INFD-IN-0001 with docs/approver-surface-requirements.md
(31da1af, 5203f46) and two corrections. Several of my requirements were wrong or
incomplete; revised rather than appended to.

Corrected:
- PR-02 listed only approval:approve. Wrong — the surface also needs
  approval:read to fetch what it renders. As drafted it would have shipped a
  client able to submit an entry it could never display. That changes a
  registration key-cape has already implemented, so it is their call (open
  question A).
- NC-03 implied approval-engine refuses non-human approver entries. It does not;
  only /consume is principal-restricted, and the operator service client holds
  approval:approve. Enforcement of "humans bind, agents draft" is therefore ours
  alone, and is auditable via schema v4's entries[].principal_type — never from
  the shape of subject_id.

Added:
- PR-04 assurance shape. approval-engine persists it verbatim and accepts an
  empty object, so it is the only place MFA survives into the approval record.
  Needs auth method, acr/amr, auth_time, agreed with key-cape.
- PR-05 entitlement. A 200 from the engine is not permission to view; we owe
  access-engine a check before rendering. Consuming a decision, not making one.
- PR-06 response mapping, including 409 duplicate_approver rendered as SUCCESS
  (a browser double-submit is routine and the first entry stands) and 503 as
  fail-closed.
- PR-07 and a matching INTENT wrongness condition: never render `approved` as
  permission to act. That is a PDP in the browser wearing UI copy.
- L-05, L-06 and EvidenceModel 8b: view_hash cannot ride into the entry — the
  POST discards its body by design — so Stage 1 correlates by (approval_id,
  subject, approved_at). DoD-3 is satisfied by the triple, not by a stored hash.

PRD open question 1 is answered by construction: there is no inbox endpoint and
there will not be one, so the approvals-inbox shape is foreclosed upstream.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:20:13 +02:00
custodian-sync
23fba00b1b chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-09:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:16:53 +02:00
a8e227851e Promote schema and canonicalizer out of history; add EvidenceModel (T06)
Verified the three published hashes reproduce byte for byte before promoting
anything, then moved the schema, canonicalizer and vectors into governed assets.
history/20260909-initial-exploration/ is untouched and stays the provenance
record.

- schemas/, informed_decision/, tests/vectors/ populated; the reference
  canonicalizer's ad-hoc __main__ block replaced by a real
  `python -m informed_decision` entry point.
- tests/test_canonicalize.py — 20 tests, all green. Published vectors, all four
  isolation properties, canonical-form round-trip, key sorting, and a provenance
  test asserting the governed fixtures have not drifted from history/.
- docs/specs/EvidenceModel.md — the two hashes, the split and why it exists, the
  four isolation properties, the presentation record, the bundle, and the
  relationship to audit-core.
- pyproject.toml, Makefile.

One test of mine was wrong on first run: it scanned for ", " to assert no
insignificant whitespace, which fires on prose inside a brief. Replaced with a
canonical round-trip comparison, which is the property actually meant. The
canonicalizer was correct.

EvidenceModel leads with what the model does NOT claim — no proof of
comprehension, no proof of reading (deliberately, since the alternative is
surveillance), no survival of a compromised surface, and audit-core's inherited
bound that a hash chain cannot prove a record was never sent.

T06 stays progress: the SCOPE.md rewrite is gated on the T02 ruling.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:16:28 +02:00
7ae67b2f4e Promote INFD-WP-0001 to active with a review note
C-23 flagged lifecycle drift: the workplan was still 'proposed' while T02 sat at
'progress'. ADR-007 correctly refuses to auto-promote, so this is a deliberate
promotion rather than a status the tool inferred.

The plan is genuinely being worked and the review it was pending has happened:
against approval-engine's INTENT/SCOPE/layer.yaml/WP-0002 and its keycape
service registrations, the accepted security layer model v0.7 and companion,
the repo-classification and project-repository-flavor standards, and the schema,
state-transition tables and vectors in history/.

Also corrected the body text, which claimed T03-T05 would all be rewritten if
the ruling differs. That was too broad: only T05 and T07 depend on the catalog
row. T03, T04 and T06 describe what the surface must do and what the evidence
must contain, and neither changes with layer placement.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:12:52 +02:00
custodian-sync
7e5fb59ddf chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-09:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:12:01 +02:00
b78c15a7ef Add PRD and Use Case Catalog; file the gate-house request (T02-T04)
T02 — intake INFD-IN-0001 filed with gate-house and messages sent to gate-house,
key-cape and approval-engine. Status progress; it now waits on an external
ruling. key-cape was told explicitly why T07 is not answering KEY-WP-0013-T02
yet — a placeholder callback URI would either fail closed or register an origin
no component owns — and given the token shape to check now rather than at T07.

T03 — ProductRequirementsDocument.md. 30 requirements, each traced to a GOAL.md
DoD item, an INTENT principle or wrongness condition, a state-transition guard,
or a named external contract, and each with an observable pass condition.
Anti-requirements are stated as testable absences: no dwell timers, no attention
analytics, no dark patterns, no auto-approval, no approval-state caching, no
authorization endpoint. Four limitations are recorded up front, including that
escalate without a mandate graph is forwarding and that view_hash is computed by
the renderer.

T04 — UseCaseCatalog.md. L0-L5 with counterparties, plus ten negative cases
bound to guards and isolation vectors. Each case records the constraint it
places on the shared schema, so scale invariance is testable rather than
asserted. Closes with the four changes that would fork the object.

T05 and T07 remain gated on the ruling. T06 is independent and is next.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:11:36 +02:00
ebd35b59cf Raise INFD-IN-0001: layer placement and approver-UI ownership
File the gate-house decision request that gates INFD-WP-0001-T02, before any
architecture is written, so the ruling constrains the design rather than being
retrofitted to it.

Three rulings requested: layer and role (proposed PEP-shaped, §6.4/companion
§5); whether a presentation attestation also makes this a PIP or must reach
consumers only through audit-core; and the relationship between view_hash and
approval-engine's binding digest.

The third is the highest risk and the reason this is filed first. Both digests
claim to canonicalize "the binding" but cover different material — the approval
digest exists without a human in the loop, view_hash covers the brief, packet,
highlights, locale and UI release. Three candidate rulings are set out with what
each costs; the proposal is distinct attestations with an explicit authority
rule, but any of the three is implementable. The outcome to avoid is both
shipping with no stated relationship.

The self-dealing objection is argued against ourselves rather than left for
review, and the residual is stated plainly: a compromised surface can present X
and attest Y, structurally the same residual approval-engine names for
adversarial omission at a compromised source. No claim is made to close it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 14:07:13 +02:00
ebfa558eb0 Use in-vocabulary capability tags
capability_families in repo-classification.allowed.yaml is a fixed list;
'experience' and 'documents' are not in it. Replaced with 'traceability' and
'participation', both in the knowledge_and_evidence family and both accurate:
this repository owns the evidence chain and the surface on which a human takes
part in a decision.

'decision-support' is in the recommended vocabulary but is still not used, for
the statute §8 reason given in the previous commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 12:40:50 +02:00
83016236c9 Use established capability tags
C-24 flagged 'user-interface' as outside the recommended family vocabulary.
Replaced with 'experience' and 'documents', both already in estate use.
Deliberately did not add 'decision-support': 'decision' is access-engine's word
under statute §8, and approval-engine withdrew its own seed wording for the
same reason. This repository renders decisions; it must not tag itself as
supporting them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 12:39:36 +02:00
309bea463e Correct repo flavor to product; add SCOPE, AGENTS, classification
fix-consistency surfaced that GOAL.md's `repo_flavor: project` was wrong.
project-repository-flavor_v0.1.md reserves the prj- flavor for bounded
cross-repo coordination efforts and says durable products use INTENT.md and an
ordinary category. informed-decision is a durable product, so the C-35
"prj- flavor forbids shipping both INTENT.md and GOAL.md" contradiction was
self-inflicted rather than a real conflict.

- .repo-classification.yaml: category product, domain infotech.
- GOAL.md: drop repo_flavor/project_status, add a flavor note explaining that
  GOAL.md is retained as the stage statement alongside a stable INTENT.md.
- SCOPE.md: honestly empty — states that nothing is implemented and that
  INFD-WP-0001-T06 rewrites it after the gate-house ruling and the specs.
- AGENTS.md: shared State Hub / session / workplan boilerplate, plus the hard
  rules for this repository — never decide, never own approval state, never
  invent identity, never let awareness enter view_hash, never let an agent
  bind, never fork the schema, fail closed.
- INFD-WP-0001: T01 records both corrections; T06 now rewrites SCOPE.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 12:38:41 +02:00
custodian-sync
0f5a6c4f59 chore(consistency): sync task status from DB [auto]
Updated by fix-consistency on 2026-09-09:
  - update .custodian-brief.md for informed-decision

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 12:36:36 +02:00
ee2cca579c Establish INTENT, Stage 1 GOAL, and founding workplan
Claim ownership of the browser-facing approver UI that approval-engine
deliberately does not contain. approval-engine's INTENT names an approvals
inbox under Non-Goals, and docs/keycape-service-registrations.md records that
the human approver client's client_id and callback URI "must come from its
owner once it exists" — leaving key-cape's KEY-WP-0013-T02 blocked on an
unassigned component.

- INTENT.md: Decision Memo concept, the binding/awareness split and the two
  hashes, ownership and non-ownership against the named estate repositories,
  and a provisional PEP-shaped layer placement flagged for a gate-house ruling
  rather than asserted.
- GOAL.md: Stage 1 is the L3 approval approver surface — the narrowest real
  consumer with a live blocking dependency — plus the written answer to who
  owns the approver UI.
- workplans/INFD-WP-0001: founding documents, the gate-house layer/ownership
  ruling, the four specs (PRD, UseCaseCatalog, ArchitectureBlueprint,
  EvidenceModel), schema and canonicalizer promotion out of history/ with the
  isolation vectors under test, the key-cape client registration, and a
  walking skeleton that includes return and discuss.

history/ is preserved unmodified as provenance.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1565372@bnt-lap001
Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568
2026-09-09 10:47:36 +02:00
771ddb9ced Initial commit 2026-09-09 06:41:05 +00:00