Record A11 r2/A12 r3 assent and the railiance-clock owner review

- A11 r2 approved; A12 r3 approved by operator decision (supersedes the
  2026-09-21 deferral of A12 r2). Flip notice will name eight checkers.
- railiance-clock review: identity vocabulary confirmed without a new
  principal type; Tooling now, PIP only once a sample API is consumed;
  execution-attribution gap assigned to NK-WP-0040 (proposed).

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 299762@bnt-lap001
Assistant-Session: d3d3cea1-869c-44f1-be2a-3d6d3550e72e

history/2026-09-23-railiance-clock-identity-and-layer-review.md

@@ -0,0 +1,100 @@
+# railiance-clock: identity attribution and layer review (2026-09-23)
+
+net-kingdom's owner review record answering railiance-clock messages `7ae214b9`
+(identity attribution and UTC prerequisites) and `460f9ecc` (foundation and
+IaC handoff).
+
+Reviewed:
+
+- `railiance-clock/docs/identity-and-utc-review.md` at `cd1cc0c`
+- `RCLK-WP-0002` at the same commit
+
+Against these NetKingdom standards at `acf0820`:
+
+- `iam-profile_v0.3` (accepted)
+- `security-layer-model_v0.7` (accepted; v0.8 is proposed and on hold)
+- `tenancy-posture_v0.1` (proposed)
+- `playbook-capability-contract_v0.1`
+- `credential-management_v0.2`
+
+This review grants nothing, provisions no principal and declares no layer on
+railiance-clock's behalf.
+
+## Ruling 1: identity vocabulary (RCLK-WP-0002-T01). Confirmed, with one gap
+
+No fourth `functional` principal type. IAM v0.3 closes `principal_type` at
+`human`, `service` and `agent`. A responsibility is not an authenticated
+actor, and giving it a token type would let a role name stand in for a
+permission, which is the first negative the review lists. Each row of the
+review's table maps to an existing owner:
+
+| Review concept | Existing contract | Owner |
+| --- | --- | --- |
+| Human principal | IAM v0.3 human flow; issuer plus `sub` | key-cape (issuer), NetKingdom (profile) |
+| Agent principal | IAM v0.3 agent flow: `agent.id`, `agent.mode`, delegating actor as `actor_sub`/`act.sub`, required tenant | NetKingdom (profile) |
+| Service principal | IAM v0.3 service flow: stable service-plus-environment subject, target audience, no cross-environment reuse | NetKingdom (profile); credentials under CMS v0.2 |
+| Workload identity | Tenancy Posture v0.1 authoritative `workload_identity` binding (Decision 5.6.2). The standard is **proposed**, so cite it as a proposed contract, not an accepted one | zone-engine (semantics), NetKingdom (publication) |
+| Functional responsibility | Playbook Capability Contract v0.1 responsibility claims and the Security Scenario Composition responsibility map. Declarative; it grants nothing | NetKingdom (contract), Railiance (declarations) |
+| Authorization role | Permission lives in the PDP (flex-auth/access-engine) and, for secret paths, in railiance-platform's central OpenBao policy. The IAM `roles` claim is a coarse identity input to that decision, not a grant | flex-auth; railiance-platform |
+| Ansible role | Railiance execution artifact. Not a principal and not a credential (Playbook Capability Contract: execution stays in Railiance) | railiance-infra |
+| Execution | **Gap, see below** | — |
+
+The audit chain the review proposes is sound: initiating actor → delegated
+agent → executing workload/runtime principal → action and target → source and
+role artifact → decision/approval references → result receipt. Its caveats are
+correct as well: an agent can be the executing workload when that is
+authoritatively declared, and a key ID identifies a trust key, not the whole
+service identity. The six negatives match IAM v0.3 and layer model §9.7.
+
+**Gap: execution attribution.** No NetKingdom contract defines the record
+that links one execution to its actor, delegation, workload binding, source
+and artifact digest, target, decision/approval references and time interval.
+IAM v0.3 defines the claims, and the Playbook Capability Contract defines
+selection and responsibility, but neither defines the run receipt. Owner work
+record: **NK-WP-0040** (proposed). It adds an execution-attribution receipt to
+the Playbook Capability Contract and names audit-core as the evidence holder.
+Until it lands, railiance-clock should use the field list in its review
+unchanged and cite NK-WP-0040 as pending.
+
+## Ruling 2: layer classification (RCLK-WP-0002-T01)
+
+Classification is railiance-clock's own declaration in its `INTENT.md`
+frontmatter (§11; A11 r2), reviewable by gate-house. net-kingdom does not
+declare it. Guidance against v0.7:
+
+- **What exists today is Tooling.** Host time discipline (timesyncd, or a
+  reviewed replacement), inventory and evidence are infrastructure and state,
+  mostly third-party (§3.2).
+- **A signed-sample authority API, once it exists and a decision consumes it,
+  is an Engine in the PIP role.** It would supply a fact (time with an error
+  bound) that a decision consumes. §3.3 makes every new engine a PIP unless the
+  standard is amended. It is never a PDP (§6), and a valid time sample is
+  never an authorization, as the review's own negative says. It is not a PEP
+  unless it causes a protected side effect itself.
+- **Do not declare the Engine layer speculatively.** Declare Tooling now, and
+  re-declare only when the sample API exists and a named consumer depends on
+  it. A new §4 catalog row goes through gate-house.
+- Declare against v0.7. v0.8 is proposed and held (GH-DEC-2026-019).
+
+## Ruling 3: consumer vocabulary and trust custody (RCLK-WP-0002-T02/T04)
+
+- Canonical consumer names are `access-engine` (the repository coordinate is
+  pending under FLEX-WP-0020; runtime names stay `flex-auth`),
+  `approval-engine`, `secrets-engine` and `audit-core`. Use the runtime name
+  where a deployed endpoint is meant.
+- Validity, CAS and check-to-use semantics belong to each consumer, as the
+  review says. Layer model §9.7 applies: every allow has an explicit lifetime,
+  and revocation has a stated visibility deadline per role. A clock
+  contributes the time a lifetime is evaluated against. It does not decide
+  whether the lifetime holds.
+- Signing-key custody for the authority follows Credential Management
+  Standard v0.2. Access to the keys is granted by railiance-platform's central
+  OpenBao policy. Any allowance railiance-clock needs goes into that central
+  policy source, not into a local role or script.
+
+## Not reviewed here
+
+The UTC source, error-model, leap and bootstrap gates (RCLK-WP-0002-T02/T03)
+belong to railiance-infra and railiance-bootstrap. The Forgejo evidence role
+and the IaC plan (RCLK-WP-0005) belong to Railiance architecture. net-kingdom
+has no finding against the review's proposed gates.

history/2026-09-23-section-11-amendments-a11r2-a12r3-positions.md

@@ -0,0 +1,23 @@
+# §11 amendments A11 r2 and A12 r3: net-kingdom's positions (2026-09-23)
+
+Recorded by net-kingdom as publication owner of
+`canon/standards/security-layer-model_v0.8.md`, answering gate-house message
+`987e52d8` (GH-DEC-2026-021, amendment set v0.3 at gate-house `39d9287`).
+These are positions only: no canon file was edited, nothing was applied, and
+v0.8 was not flipped. The v0.8 hold (GH-DEC-2026-019) and the conditions in
+`2026-09-21-v08-hold-and-section-11-amendment-positions.md` stand.
+
+## Dispositions
+
+| # | Disposition | Note |
+| --- | --- | --- |
+| A11 r2 | approved | The added sentence admits a single-repository run as a third scope. The run must name the repository, state whether it is in §4, and report a voluntary result for a repository outside §4. No other text changed. Assent to A11 as first circulated is not carried over; this is fresh assent to r2. |
+| A12 r3 | **approved** (operator decision, 2026-09-23) | A version is reached only when it is carried as a pin, and a prose citation of a prior revision is provenance. This closes the ambiguity r2 left open without widening the rule. The narrow reading benefits gate-house; gate-house disclosed that and did not approve it itself, and the operator approved it. net-kingdom's own declaration (`layer: Taxonomy`, no version in any frontmatter key or value) satisfies r2 and r3 alike. This supersedes the 2026-09-21 deferral of A12 r2. |
+
+## Flip notice (GH-WP-0004 T10/T11)
+
+Noted: re-pointing the checkers' `VALIDATED_AGAINST` to v0.8 is a post-flip
+closing condition (GH-WP-0004 T11), not a precondition of the flip. When
+net-kingdom runs the acceptance flip, the notice will name all eight checkers:
+`kings-guard`, `user-engine`, `zone-engine`, `secrets-engine`,
+`maturity-engine`, `ops-warden`, `tenant-engine` and `flex-auth`.