chittyos · chitcommit · Jun 28, 2026 · Jun 28, 2026 · Jun 28, 2026
diff --git a/CHARTER.md b/CHARTER.md
@@ -13,6 +13,7 @@ discovery_refs:
   - chittycanon://gov/governance
   - chittycanon://docs/tech/spec/context-schema
   - chittycanon://specs/chittydna-session-governance
+  - chittycanon://docs/ops/policy/chittycommand-service-boundary-contract
 ---
 
 # ChittyCommand Charter
@@ -209,7 +210,7 @@ This charter is part of a synchronized documentation triad. Changes to shared fi
 | Dependencies | CHARTER.md (Dependencies) | CLAUDE.md (Architecture) |
 | Certification badge | CHITTY.md (Certification) | CHARTER.md frontmatter `status` |
 
-**Related docs**: [CHITTY.md](CHITTY.md) (badge/one-pager) | [CLAUDE.md](CLAUDE.md) (developer guide)
+**Related docs**: [CHITTY.md](CHITTY.md) (badge/one-pager) | [CLAUDE.md](CLAUDE.md) (developer guide) | [Service-Boundary Contract](docs/architecture/service-boundary-contract.md) (`chittycanon://docs/ops/policy/chittycommand-service-boundary-contract` — implementation-gated ecosystem ownership boundaries)
 
 ## Compliance
 

diff --git a/docs/architecture/ADR-001-meta-orchestrator-extension.md b/docs/architecture/ADR-001-meta-orchestrator-extension.md
@@ -9,6 +9,11 @@ supersedes: none
 
 # ADR-001 — Extend ChittyCommand into the Tier-2 meta-orchestrator
 
+> **See also:** [Canonical Service-Boundary Contract](service-boundary-contract.md)
+> (`chittycanon://docs/ops/policy/chittycommand-service-boundary-contract`) — the
+> implementation-gated contract for ChittyOS service ownership boundaries this ADR
+> operates within.
+
 ## Context
 
 ChittyCommand exists today as a Tier-5 application: a unified life-management

diff --git a/docs/architecture/service-boundary-contract.md b/docs/architecture/service-boundary-contract.md
@@ -1,8 +1,8 @@
 ---
-uri: chittycanon://docs/architecture/chittycommand/service-boundary-contract
-namespace: chittycanon://docs/architecture
-type: contract
-version: 0.1.0
+uri: chittycanon://docs/ops/policy/chittycommand-service-boundary-contract
+namespace: chittycanon://docs/ops
+type: policy
+version: 0.2.0
 status: DRAFT
 registered_with: chittycanon://core/services/canon
 title: "ChittyOS Canonical Service-Boundary Contract (Implementation-Gated)"
@@ -16,8 +16,22 @@ discovery_refs:
 provenance:
   derived_from: adversarial canon-vs-code review, 2026-06-12
   authored: 2026-06-14
+  live_verification: 2026-06-28 (canon URI validator + ChittyOS service registry)
+modified: 2026-06-28
 ---
 
+<!--
+  URI/type note: v0.1.0 carried uri `chittycanon://docs/architecture/chittycommand/
+  service-boundary-contract` and `type: contract`. Both fail live canon validation:
+  `architecture` is not a valid docs domain (tech|legal|ops|exec|gov) and `contract`
+  is not in the frontmatter type enum (policy|spec|procedure|registry|architecture|
+  catalog|summary). v0.2.0 corrects to a validated `docs/ops/policy/...` URI and
+  `type: policy`. The file path stays under docs/architecture/ (URI ≠ file path, per
+  CHARTER.md precedent). ADR-001 still carries the same non-canonical `docs/architecture`
+  domain — logged below, not changed here.
+-->
+
+
 # ChittyOS Canonical Service-Boundary Contract (Implementation-Gated)
 
 <!-- chitty:discovery-links:start -->
@@ -64,7 +78,8 @@ canonical docs?) and a **code axis** (does live repository evidence support it?)
 |-----|------|---------|
 | `canon_confirmed` | canon | Explicitly stated in canonical ChittyCanon documentation. |
 | `canon_directional` | canon | Implied by canonical references (e.g. tier/placement) but not spelled out as an ownership rule. |
-| `code_confirmed` | code | Verified against current, service-specific repository implementation. |
+| `registry_confirmed` | live | The live ChittyOS service registry (`helper_registry_lookup`) records this ownership scope + canonical `doc_ref`. Authoritative for *ownership intent*, independent of repo-file identity. |
+| `code_confirmed` | code | Verified against current, service-specific repository implementation (the repo's own `CHARTER.md` / `package.json`). |
 | `code_drift` | code | Canon says one thing; the repo's current code/identity does not yet match. |
 | `repo_identity_drift` | code | The repo carries another service's identity (e.g. a copied ChittyCanon `CHARTER.md` / `package.json`) instead of its own. A special case of `code_drift`. |
 | `design_proposed` | both | Architecturally sound but no canonical evidence **and** no installed repo found. Must not be enforced. |
@@ -107,27 +122,80 @@ ChittyCanon               = ontology / canonical rules
 
 ## Boundary evidence table
 
-Status reflects the 2026-06-12 adversarial review. Code-side findings for **other**
-repos were reported by that review and are **not independently re-verified in this
-repository** — treat them as `code_drift` flags to confirm, not as settled fact.
+Status reflects the 2026-06-12 adversarial review **overlaid with a 2026-06-28 live
+registry verification** (see the Live Verification section below). The registry layer
+now confirms *ownership intent* for connect/auth/id/canon and records a **registry miss**
+for ChittyRouter (which scopes — but does not prove — its `hold`; see the ChittyRouter
+row). The **repo-file** identity drift (stale `CHARTER.md` / `package.json`) reported
+in 2026-06-12 remains **unverified** — that check needs read access to the other repos,
+which this session did not have. Treat repo-file `code_drift` as still-to-confirm.
 
 | Boundary claim | Status | Finding |
 |---|---|---|
-| ChittyCanon owns ontology / canonical model | `canon_confirmed` | Charter governs P/L/T/E/A ontology, URI namespace, code-pattern governance, canonical data model. Does **not** own ChittyID minting or ChittyAuth authentication. |
+| ChittyCanon owns ontology / canonical model | `canon_confirmed`, `registry_confirmed` | Charter governs P/L/T/E/A ontology, URI namespace, code-pattern governance, canonical data model. Does **not** own ChittyID minting or ChittyAuth authentication. Registry: `chittycanon` → "canonical definitions, architectural specifications" (`core/services/canon`). |
 | `Person (P, Synthetic)` is the actor class for AI/context | `canon_confirmed`, `code_confirmed` (local) | Canon defines `P` as actor-with-agency; AI contexts are `P`-Synthetic, never `Thing`; `Entity` is not a type. ChittyCommand's own T→P re-mint is the local instance. |
 | Context persistent; session ephemeral viewport/worker | `canon_confirmed` | Context has ChittyID, ledger, DNA, trust; session runs under a context's ChittyID as working memory. |
-| ChittyConnect owns connectivity / context binding | `canon_confirmed`, `code_drift` | Governance maps Connectivity (VY) and context binding to ChittyConnect. But `chittyos/chittyconnect`'s `CHARTER.md` / `package.json` reportedly identify as **ChittyCanon** → `repo_identity_drift`. |
-| ChittyAuth owns auth / access | `canon_confirmed`, `code_drift` | Governance maps Authority (RY) access to ChittyAuth. But `chittyfoundation/chittyauth` reportedly carries a ChittyCanon charter/package identity → `repo_identity_drift`. |
-| ChittyID owns identity minting | `canon_confirmed`, `code_drift` | Context spec: ChittyID mints IDs for synthetic contexts. But `chittyfoundation/chittyid` reportedly carries a ChittyCanon charter/package identity → `repo_identity_drift`. |
-| ChittyRouter owns routing | `canon_directional`, `code_drift` / `hold` | Ecosystem reference places ChittyRouter in Tier-2 platform infrastructure. Earlier repo checks suggested `chittyos/chittyrouter` also looked copied/stale as ChittyCanon → `hold` until a real ChittyRouter pentad/code surface is verified. |
-| ChittyTasks owns credential-origination task routing | `design_proposed` / `hold_blocked` | No installed repo named `chittytasks`/`chittytask` found. Concept is sound, but the capability-governor rule forbids inventing a boundary without canonical evidence → `hold`. |
+| ChittyConnect owns connectivity / context binding | `canon_confirmed`, `registry_confirmed`; repo-file `code_drift` *unverified* | Registry: `chittyconnect` → "service connections, credential proxying, API access" (`core/services/connect`, connect.chitty.cc) — confirms ownership. The 2026-06-12 report that `chittyos/chittyconnect`'s `CHARTER.md`/`package.json` identify as **ChittyCanon** (`repo_identity_drift`) is **not re-verified** this session. |
+| ChittyAuth owns auth / access | `canon_confirmed`, `registry_confirmed`; repo-file `code_drift` *unverified* | Registry: `chittyauth` → "authorization, access control, permissions" (`core/services/auth`, auth.chitty.cc) — confirms ownership. Reported `repo_identity_drift` on `chittyfoundation/chittyauth` **not re-verified** this session. |
+| ChittyID owns identity minting | `canon_confirmed`, `registry_confirmed`; repo-file `code_drift` *unverified* | Registry: `chittyid` → "identity management, user authentication, DID resolution" (`core/services/identity`, id.chitty.cc) — confirms ownership. Reported `repo_identity_drift` on `chittyfoundation/chittyid` **not re-verified** this session. |
+| ChittyRouter owns routing | `canon_directional`, `hold` (registry miss only) | Live registry returns **"System not found: chittyrouter"** — so there is no registry *ownership* scope/`doc_ref` to enforce against. This is a **registry-lookup miss, NOT evidence the service is absent**: ChittyRouter is integrated in this repo (`wrangler.jsonc` → `CHITTYROUTER_URL=https://router.chitty.cc`) and declared an upstream "unified ingestion gateway" in `CHARTER.md`. The hold is scoped to *canonical routing-ownership evidence* (which the registry does not currently carry) — do **not** read it as routing being ownerless. |
+| ChittyTasks owns credential-origination task routing | `design_proposed` / `hold_blocked` | No installed repo named `chittytasks`/`chittytask` found, and no registry entry probed. Concept is sound, but the capability-governor rule forbids inventing a boundary without canonical evidence → `hold`. |
 
 > **Note on local naming:** within ChittyCommand, "tasks" capability is satisfied
 > by the `chittyagent-tasks` durable-queue pattern reused for intent dispatch and
 > `node_leases` (see `CHARTER.md` → Dependencies, and `daemon/leader.ts`). That is
 > **not** the same thing as a canonical `ChittyTasks` service owning
 > credential-origination routing; the latter remains `design_proposed`.
 
+## Live verification (2026-06-28)
+
+A live status sweep of the canon validator and the ChittyOS service registry was
+run on 2026-06-28. Results are recorded here as dated evidence; re-run before
+relying on them.
+
+### Service-registry ownership (`helper_registry_lookup`)
+
+| System | Ownership scope (registry) | `doc_ref` | Interface | `last_verified` |
+|---|---|---|---|---|
+| `chittyid` | identity management, user authentication, DID resolution | `chittycanon://core/services/identity` | id.chitty.cc | 2026-01-06 |
+| `chittyconnect` | service connections, credential proxying, API access | `chittycanon://core/services/connect` | connect.chitty.cc | 2026-01-06 |
+| `chittyauth` | authorization, access control, permissions | `chittycanon://core/services/auth` | auth.chitty.cc | 2026-01-06 |
+| `chittycanon` | canonical definitions, architectural specifications | `chittycanon://core/services/canon` | canon.chitty.cc | 2026-01-06 |
+| `chittyrouter` | **not found** | — | — | — |
+
+The registry confirms ownership intent for the four registered services. The
+`chittyrouter` row is a **registry-lookup miss, not a statement that routing is absent** —
+ChittyRouter is integrated in this repo (`wrangler.jsonc` `CHITTYROUTER_URL`, and a
+`CHARTER.md` upstream dependency). It means only that the registry carries no canonical
+*routing-ownership* record to enforce against, which is what scopes the `hold`. Registry
+`last_verified` stamps are themselves stale (2026-01-06), so this is ownership-of-record,
+not a liveness guarantee.
+
+### Canon URI / frontmatter validation
+
+- This document's v0.1.0 URI (`chittycanon://docs/architecture/...`) and
+  `type: contract` **both failed** live canon validation. Corrected in v0.2.0 to
+  `chittycanon://docs/ops/policy/chittycommand-service-boundary-contract`
+  (validated clean) and `type: policy` (in the frontmatter enum).
+- **Discovered drift:** [ADR-001](ADR-001-meta-orchestrator-extension.md) carries
+  the same non-canonical `chittycanon://docs/architecture/chittycommand/ADR-001`
+  URI. Left unchanged here (changing a referenced canonical URI is out of scope for
+  this doc), but logged as a `canonical_drift_blocked` candidate for a follow-up.
+- **Registered:** this contract was registered with the canonical registry
+  (`canon_register_document`) on 2026-06-28T07:08:14Z → `registered: true`,
+  status `DRAFT` (authority: none, as expected for a draft).
+
+### Availability (not identity)
+
+- `canon` service `/health` was **down** (canon.chitty.cc non-200 on all probes) and
+  the MCP aggregator `mcp.chitty.cc` returned 404 — yet the canon **MCP surface**
+  (URI validation, frontmatter schema) responded normally. Availability drift is
+  orthogonal to the ownership boundaries above; recorded so a future reader does not
+  mistake a health blip for a boundary change.
+- The health probe covers the `chittyagent-*` MCP federation only; `id` / `connect` /
+  `router` are platform infrastructure and are not in it (consistent with them not
+  being MCP agents).
+
 ## Enforcement rule
 
 Before any consumer (code, telemetry, downstream contract, or agent policy)
@@ -149,12 +217,16 @@ The model is **canonically consistent** as a *target* contract. Current code and
 capability evidence says:
 
 ```text
-doc_code_aligned:        partially
-repo_identity_drift:     present (chittyconnect, chittyauth, chittyid; chittyrouter on hold)
+canon_alignment:         confirmed (this doc's own URI/type now validate clean)
+registry_ownership:      confirmed for chittyid / chittyconnect / chittyauth / chittycanon
+chittyrouter:            hold — registry miss only (still integrated via wrangler.jsonc / CHARTER)
+repo_identity_drift:     reported 2026-06-12, NOT re-verified (no repo read access this session)
 implementation_maturity: not enough to claim deployed
 chittytasks:             design-proposed unless found elsewhere
 ```
 
 This preserves the intended ChittyOS architecture without pretending the current
-repos fully implement it. Update this contract as repos shed `repo_identity_drift`
-and earn `code_confirmed` status, boundary by boundary.
+repos fully implement it. The 2026-06-28 sweep moved ownership intent from *reported*
+to *registry-confirmed*; the remaining gap is repo-file `code_confirmed` (reading each
+service's own `CHARTER.md` / `package.json`). Update this contract as that evidence
+lands, boundary by boundary.
diff --git a/docs/registration/CHITTYID_REMINT_STATUS.md b/docs/registration/CHITTYID_REMINT_STATUS.md
@@ -0,0 +1,71 @@
+# ChittyID Re-Mint Status — T → P-Synthetic
+
+**Status:** `PENDING` (operator action) · **Last updated:** 2026-06-28
+
+A single status anchor for ChittyCommand's ChittyID re-mint. This file tracks
+*state and blockers only* — the mint **mechanics** live in
+[`SUBMISSION_RUNBOOK.md`](SUBMISSION_RUNBOOK.md) (step 3 + the substitution table)
+and must not be duplicated here.
+
+## Why this re-mint exists
+
+ChittyCommand is a sovereign meta-orchestrator that takes autonomous action
+(intent execution, sovereignty enforcement, channel fanout). Per canon, an actor
+with agency is a **Person — Synthetic** (`P`-Synthetic), never a `Thing`. This is
+the live, in-repo instance of the actor-class rule asserted in the
+[Service-Boundary Contract](../architecture/service-boundary-contract.md)
+(`chittycanon://docs/ops/policy/chittycommand-service-boundary-contract`) — the one
+boundary that can move from `code_drift` to `code_confirmed` entirely within this repo.
+
+## Identity transition
+
+| | Value |
+|---|---|
+| Current (deprecated) | `03-1-USA-3846-T-2602-0-57` — 5th field `T` (Thing) |
+| Target shape | `VV-G-USA-NNNN-P-YM-S-X` — 5th field `P`, subtype Synthetic |
+| Mint path | `ch1tty → ChittyConnect → chittyid` (sensitive-intent broker; operator never handles the bearer) |
+| Verify | 5th `-`-separated field of the minted ID is `P` before it is substituted into the payload |
+
+The deprecated T-type ID is retained for historical lookup only and must **not** be
+cited as the service identity in new code, telemetry, or downstream contracts after
+the re-mint.
+
+## What it blocks (from `CHARTER.md` → Compliance)
+
+- Formal **ChittyCertify at Tier 2**
+- **Sovereign-intent signing**
+- **ChittyTrust** score binding for the service-as-actor
+
+## Where it is tracked (do not let these drift apart)
+
+| Artifact | Role |
+|---|---|
+| `CHARTER.md` → Compliance | Authoritative checkbox + blocker list |
+| `docs/registration/chittycommand-registration-payload.json` | `chittyId: <<PENDING_P_SYNTHETIC_CHITTYID>>`, `metadata.previousChittyId` recorded |
+| `docs/registration/SUBMISSION_RUNBOOK.md` | Mint + substitution + submission mechanics |
+| `docs/architecture/service-boundary-contract.md` | The actor-class boundary this satisfies |
+| **this file** | At-a-glance status + blocker anchor |
+
+## Definition of done
+
+1. New `P`-Synthetic ChittyID minted via the ChittyConnect path and `P` verified in the 5th field.
+2. Payload placeholder substituted at submission time (never committed in plaintext).
+3. `register.chitty.cc` returns 2xx; registry search shows `tier: 2` + the new ID.
+4. `CHARTER.md` Compliance checkbox flipped, with redacted registration evidence recorded.
+5. Service-Boundary Contract row for `Person (P, Synthetic)` reaches `code_confirmed`.
+   (It currently carries the local note "re-mint pending"; drop that qualifier once
+   the new ID is live so the canonical status tag stands alone.)
+
+## Authorization
+
+Advancing any step is a **sensitive intent** (minting service identity), so it is
+**`requires_human`** under the sovereignty model — never an autonomous action. The
+authorized actor is the **ChittyCommand service owner / operator** (ADR-001: "nb
+(operator)"; `CHARTER.md` → Ownership), acting through the
+`ch1tty → ChittyConnect → chittyid` sensitive-intent broker per
+[`SUBMISSION_RUNBOOK.md`](SUBMISSION_RUNBOOK.md). No service token or autonomous
+executor may self-advance the re-mint; if the broker path is unavailable, fail
+closed (`POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE`).
+
+> This file does not mint, submit, or handle tokens. It is a tracker. Operator action
+> via the runbook is required to advance any step above.