Separate generic capability, selected proof, and portability evidence in the checked roadmap

[George-RD]

What to build

Design report: Can openspine-schemas and openspine-authority natively carry (tenant, principal, contact) as identity dimensions without violence to the current design? Separate generic capability, selected proof evidence, and portability evidence as distinct findings.

Acceptance criteria

1. Analyze current schema and authority structure. 2. Propose native (tenant, principal, contact) dimensions. 3. Identify schema changes required. 4. Document design report with findings (no implementation).

Blocked by

None (assessment; findings feed T21)

Original report

Why

The current checked capability map names the missing capability as recurring Gmail drafts and then also selects recurring Gmail drafts as the starter proof. That conflates three different truths:

1. generic capability — protocol-neutral progressive delegation / reviewed reusable responsibility;
2. selected vertical proof — recurring Gmail draft creation for one reviewed scope;
3. portability status — whether a second materially different protocol has demonstrated that the architecture is not secretly Gmail-specific.

This confusion propagates into the generated public roadmap and makes implementation details look like the product architecture. The capability map is intended to prevent documentation overclaiming, so its schema must be able to represent the corrected dependency/evidence model.

Scope

1. Capability-map schema

Extend capabilities/capability-map.json and its validator/renderer to represent, at minimum:

• generic capability ID and owner outcome;
• state: runtime substrate, product surface missing, proof in progress, wired into Lyra;
• architecture/dependency issues or settled changes;
• selected proof IDs as separate records;
• proof scope and current limits;
• named owner-path tests required to mark the generic capability wired;
• portability/conformance evidence distinct from the first proof;
• later maturity stage for whole-responsibility composition.

The schema should not treat issue numbers as runtime evidence. Issues explain blockers; archived changes, artifact paths, and named tests prove landed behavior.

2. Correct the current records

Represent:

• Capability: protocol-neutral progressive delegation / reviewed reusable responsibility.
• Current state: product surface missing.
• Landed substrate: standing rules, reflection miner, governed artifact lifecycle, task grants, budgets, expiry, revocation, and audit.
• Missing prerequisites: Define the protocol-neutral responsibility contract above standing rules #126, Unify approved and delegated effect execution; fail closed on missing executors #127, Mine and match reusable authority by kernel-resolved scope #128, Add channel-neutral responsibility review and lifecycle controls #129, Make reusable-authority evaluation proposal-specific and evidence-backed #133.
• Selected proof: Ship recurring Gmail drafts as the first complete delegation proof #130 recurring Gmail draft for one reviewed connector/account/relationship scope.
• Portability proof: Prove progressive delegation is portable across communication protocols #131.
• Whole-responsibility progression: Compose whole responsibilities from workflows, triggers, authority, and exception policy #132.

Keep the existing selected Gmail workflow because it is still the best first proof; stop describing it as the capability itself.

3. CI truth rules

• A generic capability cannot be wired_into_lyra without named owner-path tests for a real positive effect and required fallback/control cases.
• A proposal renderer, standing-rule activation test, or runtime primitive alone cannot satisfy the owner-path requirement.
• The selected proof may be marked complete independently of portability, but public copy must then say “first shipped proof,” not “works across protocols.”
• Portability cannot be marked verified until the second-protocol conformance suite in Prove progressive delegation is portable across communication protocols #131 passes.
• Whole-responsibility maturity cannot be inferred from one effect shortcut.
• Every evidence path and test name remains checked, as today.
• The generated roadmap remains deterministic and replaces only its generated block.

4. Public roadmap output

The generated section should show a dependency/maturity structure such as:

Progressive delegation — product surface missing
  Landed substrate: ...
  Architecture contract: #126
  Execution/review foundations: #127, #129
  Scoped evidence/matching: #128
  Proposal-specific evaluation: #133
  Selected proof: recurring Gmail drafts (#130)
  Portability proof: second communication shape (#131)
  Whole-responsibility progression: #132

Do not render open issues as if they were shipped features.

Tests

Use TDD on the Node capability-map tooling:

• generic capability and proof are distinct schema objects;
• exactly one selected next proof remains supported without requiring that proof to be the capability;
• a completed proof without owner-path tests fails validation;
• a generic wired claim based only on runtime changes fails;
• a portability claim without second-protocol evidence fails;
• issue dependencies render as blockers, not repository proof;
• deterministic rendering and existing archived-change/path checks remain intact;
• migration from the current JSON schema is explicit and validated.

Done when

• The checked source and public roadmap call progressive delegation the capability and Gmail the first proof.
• CI can distinguish runtime substrate, selected proof, wired owner outcome, portability, and whole-responsibility maturity.
• Documentation cannot use the Gmail proof to imply other communication protocols already work.
• Ship recurring Gmail drafts as the first complete delegation proof #130/Prove progressive delegation is portable across communication protocols #131/Compose whole responsibilities from workflows, triggers, authority, and exception policy #132 can advance their own evidence fields without rewriting the generic capability identity.

Relationship

Parent: #123.

Depends on vocabulary from #126. It may land before the runtime foundations as a truthful roadmap/tooling slice, but it must not mark any missing capability complete.

[coderabbitai]

Coding Plan

Summary

• Promote proofs to a first-class top-level proofs[] array and add generic and blocking_issues to capabilities, so the schema separates generic capability, selected proof, and portability status.
• Add an explicit, idempotent, tested migration that bumps the schema from version 1 to version 2, following the repo <subject>_migration convention.
• Extend the validator with TDD to enforce the CI truth rules: generic wiring needs positive-effect and fallback/control tests, shipped proofs need owner-path tests, portability needs second-protocol conformance evidence, and issue numbers are never runtime evidence.
• Update the deterministic renderer to show landed substrate, role-grouped blockers, and the selected/portability/whole-responsibility maturity lines, and regenerate only the roadmap generated block.

Design Choices

Design Choice 1: How should the schema separate capability records from proof records?

Options Considered:

1. Nest a proofs[] array inside each capability record.
2. Promote proofs to a first-class top-level proofs[] array whose entries reference a capability id, and retire starter_workflow_candidates.

Chosen Option: 2

Rationale: The ticket requires generic capability and proof to be distinct schema objects, plus separate records for the selected proof, portability proof, and whole-responsibility progression. Option 2 keeps the "exactly one selected" invariant that already exists on starter_workflow_candidates. It lets #130/#131/#132 advance their own evidence fields without touching the generic capability identity. It matches the ticket phrase "selected proof IDs as separate records."

Design Choice 2: Does the stricter positive effect plus fallback/control tests rule apply to every wired_into_lyra capability or only to the generic capability?

Options Considered:

1. Apply the stricter rule to all wired capabilities and relabel existing tests.
2. Mark the generic capability with a generic: true flag and apply the stricter positive-effect + fallback/control rule only to generic capabilities. Keep the existing "at least one owner-path test" rule for vertical capabilities.

Chosen Option: 2

Rationale: The existing wired vertical capabilities (direct-terminal-conversation, selected-gmail-draft) each have owner-path tests that are not labelled by category. The ticket text says: "A generic capability cannot be wired_into_lyra without named owner-path tests for a real positive effect and required fallback/control cases." This scopes the stricter rule to the generic capability. It avoids churn on already-valid vertical records.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Define the v2 schema, migration, and corrected records

This phase establishes the corrected data model. It bumps the schema to version 2. It adds an explicit, tested migration from version 1. It rewrites the checked JSON so progressive delegation is the capability and Gmail is the first proof.

Task 1: Define the version 2 schema shape

Document and adopt the extended structure that separates capability, proof, and portability truths.

• Set the top-level schema_version to 2.
• Extend each capabilities[] entry with: generic (boolean; identifies the protocol-neutral capability), and blocking_issues (array of {issue: integer, role: string} where role is one of the ticket labels: architecture contract, execution/review foundations, scoped evidence/matching, proposal-specific evaluation).
• Add a new capability state value proof_in_progress alongside the existing runtime_landed, product_surface_missing, and wired_into_lyra.
• Allow each owner_path_tests entry to carry a kind of positive_effect, fallback, or control so generic wiring can require both a positive effect and fallback/control coverage.
• Introduce a top-level proofs[] array replacing starter_workflow_candidates[]. Each proof holds: id, capability (reference to a capability id), kind (selected, portability, whole_responsibility, or candidate), selected (boolean), owner_outcome, reason, scope, current_limit, state (planned, in_progress, shipped, verified), tracking_issue, optional proof_sequence, and evidence fields owner_path_tests (for the selected proof) and conformance_tests (for the portability proof).
• Record that blocking_issues and tracking_issue are issue references that explain blockers only. They are never runtime evidence.

Task 2: Add an explicit, tested migration from version 1 to version 2

Provide a deterministic, idempotent transform following the repo <subject>_migration convention.

• Create scripts/capability-map-migration.mjs exporting a migrateCapabilityMap(map) function.
• For a version 1 map, perform the mechanical shape changes: set schema_version to 2, add generic: false and blocking_issues: [] to every capability, and rename starter_workflow_candidates to proofs.
• Map each old candidate to a proof record: the previously selected candidate becomes kind: "selected" with its task_boundary moved into scope. Unselected candidates become kind: "candidate". Preserve uses_capabilities[0] as the capability reference.
• Make the transform idempotent: if the input is already schema_version: 2, return it unchanged.
• Create scripts/capability-map-migration.test.mjs that asserts migrating the prior version 1 shape yields a structurally valid version 2 object and that re-running the migration is a no-op.
• Update scripts/check.sh to run node --test scripts/capability-map-migration.test.mjs next to the existing capability-map test invocation.

Task 3: Rewrite the checked JSON with corrected records

Author the corrected version 2 content so documentation stops overclaiming.

• Replace the recurring-draft-responsibility capability with a generic capability progressive-delegation (generic: true, state: product_surface_missing, protocol-neutral owner_outcome).
• Populate its landed substrate in runtime_changes and canonical_specs using the archived changes and specs confirmed during exploration: standing rules, reflection miner, governed artifact lifecycle, task grants and grant chain, budget hardening, spend kill switch, and audit artifact store. Confirm every change id appears in the ledger's ## Completed / archived section and every spec path exists.
• Populate blocking_issues with #126 (architecture contract), #127 and #129 (execution/review foundations), #128 (scoped evidence/matching), and #133 (proposal-specific evaluation).
• Keep the existing selected-gmail-draft capability as a shipped vertical capability. Do not describe it as the generic capability.
• Add three proofs referencing progressive-delegation: recurring-gmail-draft (kind: selected, selected: true, tracking_issue: 130, scope = one reviewed connector/account/relationship, reuse the existing five-step proof_sequence), second-protocol-portability (kind: portability, tracking_issue: 131), and whole-responsibility-progression (kind: whole_responsibility, tracking_issue: 132). Leave their evidence arrays empty because these proofs are not yet shipped.
• Keep the other pre-existing candidates (task-and-reminder, research-and-brief, skill-install-proof) as kind: candidate proofs with selected: false.

🤖 Prompt for AI agents

Implement the version 2 data model for the capability map: bump the schema, add
a tested migration, and rewrite the checked JSON content.

First, define the version 2 schema shape:
- Set the top-level `schema_version` to `2`.
- Extend each `capabilities[]` entry with `generic` (boolean) and
`blocking_issues` (array of `{issue: integer, role: string}`, where `role` is
one of `architecture contract`, `execution/review foundations`, `scoped
evidence/matching`, `proposal-specific evaluation`).
- Add `proof_in_progress` as a new valid capability `state`, alongside
`runtime_landed`, `product_surface_missing`, and `wired_into_lyra`.
- Allow each `owner_path_tests` entry to carry a `kind` of `positive_effect`,
`fallback`, or `control`.
- Replace `starter_workflow_candidates[]` with a top-level `proofs[]` array.
Each proof entry has: `id`, `capability` (reference to a capability id), `kind`
(`selected`, `portability`, `whole_responsibility`, or `candidate`), `selected`
(boolean), `owner_outcome`, `reason`, `scope`, `current_limit`, `state`
(`planned`, `in_progress`, `shipped`, `verified`), `tracking_issue`, optional
`proof_sequence`, `owner_path_tests` (for the selected proof), and
`conformance_tests` (for the portability proof).
- Treat `blocking_issues` and `tracking_issue` strictly as issue references for
blockers. Never treat them as runtime evidence.

Second, add the migration module:
- Create `scripts/capability-map-migration.mjs` that exports
`migrateCapabilityMap(map)`.
- For a version 1 input, set `schema_version` to `2`, add `generic: false` and
`blocking_issues: []` to every capability, and rename
`starter_workflow_candidates` to `proofs`.
- Convert the previously selected candidate to `kind: "selected"`, moving
`task_boundary` into `scope`. Convert unselected candidates to `kind:
"candidate"`. Preserve `uses_capabilities[0]` as the `capability` reference.
- Make the function idempotent: return the input unchanged if `schema_version`
is already `2`.
- Create `scripts/capability-map-migration.test.mjs` with tests that confirm
migrating a version 1 map produces a structurally valid version 2 object, and
that migrating twice is a no-op.
- Update `scripts/check.sh` to also run `node --test
scripts/capability-map-migration.test.mjs`.

Third, rewrite `capabilities/capability-map.json`:
- Replace `recurring-draft-responsibility` with a generic capability
`progressive-delegation` (`generic: true`, `state: product_surface_missing`,
protocol-neutral `owner_outcome`).
- Populate `runtime_changes` and `canonical_specs` with the confirmed archived
changes and specs: standing rules, reflection miner, governed artifact
lifecycle, task grants and grant chain, budget hardening, spend kill switch, and
audit artifact store. Verify each change id is in the `## Completed / archived`
section of `openspec/openspine-change-sequence.md` and each spec path exists.
- Populate `blocking_issues` with `#126` (`architecture contract`), `#127` and
`#129` (`execution/review foundations`), `#128` (`scoped evidence/matching`),
`#133` (`proposal-specific evaluation`).
- Keep `selected-gmail-draft` as a shipped vertical capability, distinct from
the generic capability.
- Add proofs referencing `progressive-delegation`: `recurring-gmail-draft`
(`kind: selected`, `selected: true`, `tracking_issue: 130`, scope of one
reviewed connector/account/relationship, reused five-step `proof_sequence`),
`second-protocol-portability` (`kind: portability`, `tracking_issue: 131`),
`whole-responsibility-progression` (`kind: whole_responsibility`,
`tracking_issue: 132`). Leave evidence arrays empty for these because they are
not shipped.
- Keep `task-and-reminder`, `research-and-brief`, `skill-install-proof` as
`kind: candidate` proofs with `selected: false`.

Phase 2: Extend the validator with the new truth rules (TDD)

This phase encodes the CI truth rules. Write the tests first. Then extend the validator so it enforces the separation of capability, proof, and portability evidence.

Task 1: Add validator tests for the corrected model

Drive the validator changes from failing tests in the existing suite.

• Update the validMap() factory and fixtureRoot() helper in scripts/capability-map.test.mjs to produce a valid version 2 map (a generic capability with categorized owner-path tests, a top-level proofs[] array, and fixtures for any referenced test/spec/artifact paths).
• Add tests asserting: the generic capability and a proof are distinct objects; exactly one proof has selected: true; a proof with state: shipped and empty owner_path_tests fails; a generic capability marked wired_into_lyra with only runtime_changes and no positive-effect and fallback/control owner-path tests fails; a portability proof marked state: verified with empty conformance_tests fails.
• Add a test asserting blocking_issues are rejected wherever runtime evidence is expected (for example, an integer issue placed in runtime_changes fails).
• Keep the existing archived-change, path-existence, and registered-test tests intact against the new fixtures.

Task 2: Extend `validateCapabilityMap`

Implement the rules to make the new tests pass in scripts/capability-map.mjs.

• Change the schema_version check to require 2. Add proof_in_progress to VALID_STATES.
• Validate blocking_issues entries: issue must be an integer, role must be a non-empty string. Ensure blocking issues never substitute for or appear in runtime_changes. Reject non-string or integer-like entries in runtime_changes.
• For a capability with generic: true and state: wired_into_lyra, require at least one positive_effect owner-path test and at least one fallback or control owner-path test. Keep the existing "at least one owner-path test" rule for non-generic wired capabilities.
• Validate the new proofs[] array: exactly one selected: true; every capability reference must be a known capability id; the selected proof requires an integer tracking_issue, a proof_sequence of at least four steps, and a referenced capability whose state is product_surface_missing or proof_in_progress.
• Enforce proof evidence rules: a proof with state: shipped requires non-empty owner_path_tests; a kind: portability proof with state: verified requires non-empty conformance_tests; a kind: whole_responsibility proof cannot reach state: verified unless the selected proof is shipped and the portability proof is verified.
• Reuse the existing path-existence and hasRegisteredRustTest checks for every owner_path_tests and conformance_tests entry.

🤖 Prompt for AI agents

Follow TDD to add the CI truth rules to the capability map validator. Write
failing tests first in `scripts/capability-map.test.mjs`, then extend
`validateCapabilityMap` in `scripts/capability-map.mjs` to make them pass.

Step 1, update the tests:
- Update the `validMap()` factory and `fixtureRoot()` helper to produce a valid
version 2 map: a generic capability with categorized owner-path tests, a
top-level `proofs[]` array, and fixtures for referenced test/spec/artifact
paths.
- Add a test confirming the generic capability and a proof are distinct objects.
- Add a test confirming exactly one proof has `selected: true`.
- Add a test confirming a proof with `state: shipped` and empty
`owner_path_tests` fails validation.
- Add a test confirming a generic capability marked `wired_into_lyra` with only
`runtime_changes` and no positive-effect and fallback/control owner-path tests
fails validation.
- Add a test confirming a portability proof marked `state: verified` with empty
`conformance_tests` fails validation.
- Add a test confirming `blocking_issues` are rejected wherever runtime evidence
is expected, for example an integer issue placed in `runtime_changes`.
- Keep the existing archived-change, path-existence, and registered-test tests
working against the new fixtures.

Step 2, extend `validateCapabilityMap`:
- Require `schema_version` equal to `2`. Add `proof_in_progress` to
`VALID_STATES`.
- Validate `blocking_issues` entries: `issue` must be an integer, `role` must be
a non-empty string. Reject blocking issues appearing in or substituting for
`runtime_changes`. Reject non-string or integer-like entries in
`runtime_changes`.
- For a capability with `generic: true` and `state: wired_into_lyra`, require at
least one `positive_effect` owner-path test and at least one `fallback` or
`control` owner-path test. Keep the existing rule of "at least one owner-path
test" for non-generic wired capabilities.
- Validate `proofs[]`: exactly one entry with `selected: true`; every
`capability` reference resolves to a known capability id; the selected proof
must have an integer `tracking_issue`, a `proof_sequence` of at least four
steps, and reference a capability with state `product_surface_missing` or
`proof_in_progress`.
- Enforce proof evidence rules: `state: shipped` requires non-empty
`owner_path_tests`; `kind: portability` with `state: verified` requires
non-empty `conformance_tests`; `kind: whole_responsibility` cannot reach `state:
verified` unless the selected proof is `shipped` and the portability proof is
`verified`.
- Reuse the existing path-existence and `hasRegisteredRustTest` checks for every
entry in `owner_path_tests` and `conformance_tests`.

Phase 3: Update the renderer and regenerate the public roadmap

This phase makes the generated roadmap show the corrected dependency and maturity structure. It keeps rendering deterministic and confined to the generated block.

Task 1: Update the roadmap renderer

Render the maturity structure and blockers in scripts/capability-map.mjs.

• Update the summary count line to reflect the new states, including any proof_in_progress capabilities, without breaking the existing count format for the other states.
• Render the generic capability with its landed substrate, then a grouped-by-role list of blocking_issues under labels such as Architecture contract, Execution/review foundations, Scoped evidence/matching, and Proposal-specific evaluation. Render these as issue links, and keep them out of the "Repository proof" column.
• Render Selected proof, Portability proof, and Whole-responsibility progression lines for the generic capability, each linking its tracking issue.
• Apply the public-copy rule: if the selected proof is shipped but the portability proof is not verified, render "first shipped proof" language and do not claim the capability works across protocols.
• Keep evidenceMarkdown showing only archived changes, specs, and named tests as proof. Never render issue numbers as proof.
• Add a rendering determinism test in scripts/capability-map.test.mjs that asserts the blockers appear grouped by role, the three proof lines render with their issue links, and issue numbers do not appear in the proof column.

Task 2: Regenerate the roadmap file

Produce the deterministic output and confirm the manual content is preserved.

• Run node scripts/capability-map.mjs --write to regenerate the block in site/src/content/docs/roadmap.md.
• Confirm the frontmatter, intro paragraphs, and all sections after <!-- capability-map:end --> remain byte-for-byte identical.
• Confirm the read-only node scripts/capability-map.mjs staleness check passes after the write.

🤖 Prompt for AI agents

Update the roadmap renderer in `scripts/capability-map.mjs` to reflect the
corrected maturity structure, and regenerate the public roadmap file.

Renderer changes:
- Update the summary count line to reflect the new states, including any
`proof_in_progress` capabilities. Do not break the existing count format for the
other states.
- Render the generic capability together with its landed substrate. Follow it
with a list of `blocking_issues` grouped by role, using labels `Architecture
contract`, `Execution/review foundations`, `Scoped evidence/matching`, and
`Proposal-specific evaluation`. Render these as issue links. Keep them out of
the "Repository proof" column.
- Render `Selected proof`, `Portability proof`, and `Whole-responsibility
progression` lines for the generic capability. Link each to its tracking issue.
- Apply the public-copy rule: if the selected proof is `shipped` but the
portability proof is not `verified`, render "first shipped proof" language. Do
not claim the capability works across protocols in this case.
- Keep `evidenceMarkdown` showing only archived changes, specs, and named tests
as proof. Never render issue numbers as proof.
- Add a rendering determinism test in `scripts/capability-map.test.mjs`
confirming: blockers appear grouped by role, the three proof lines render with
their issue links, and issue numbers do not appear in the proof column.

Regeneration steps:
- Run `node scripts/capability-map.mjs --write` to regenerate the generated
block in `site/src/content/docs/roadmap.md`.
- Confirm the frontmatter, intro paragraphs, and all content after `<!--
capability-map:end -->` remain byte-for-byte identical.
- Confirm the read-only invocation `node scripts/capability-map.mjs` passes its
staleness check after the write.

Research

The capability map is a single JSON file at capabilities/capability-map.json (schema_version: 1). It holds a flat capabilities[] array and a starter_workflow_candidates[] array.

scripts/capability-map.mjs does these tasks:

• It validates the JSON against the archived-change ledger (openspec/openspine-change-sequence.md).
• It verifies that every canonical_specs/lyra_artifacts path exists.
• It confirms that each owner_path_tests entry names a real registered Rust test.
• It renders a deterministic Markdown block into site/src/content/docs/roadmap.md between <!-- capability-map:start --> and <!-- capability-map:end -->.

scripts/capability-map.test.mjs (Node node:test) exercises these exported functions with temp-dir fixtures.

scripts/check.sh runs the test file and the validator in CI (.github/workflows/ci.yml).

The repo convention for schema evolution is a dedicated <subject>_migration module with a co-located test file, plus a schema_version shape field that the validator hard-checks.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the version 2 data model for the capability map: bump the schema, add
a tested migration, and rewrite the checked JSON content.

First, define the version 2 schema shape:
- Set the top-level `schema_version` to `2`.
- Extend each `capabilities[]` entry with `generic` (boolean) and
`blocking_issues` (array of `{issue: integer, role: string}`, where `role` is
one of `architecture contract`, `execution/review foundations`, `scoped
evidence/matching`, `proposal-specific evaluation`).
- Add `proof_in_progress` as a new valid capability `state`, alongside
`runtime_landed`, `product_surface_missing`, and `wired_into_lyra`.
- Allow each `owner_path_tests` entry to carry a `kind` of `positive_effect`,
`fallback`, or `control`.
- Replace `starter_workflow_candidates[]` with a top-level `proofs[]` array.
Each proof entry has: `id`, `capability` (reference to a capability id), `kind`
(`selected`, `portability`, `whole_responsibility`, or `candidate`), `selected`
(boolean), `owner_outcome`, `reason`, `scope`, `current_limit`, `state`
(`planned`, `in_progress`, `shipped`, `verified`), `tracking_issue`, optional
`proof_sequence`, `owner_path_tests` (for the selected proof), and
`conformance_tests` (for the portability proof).
- Treat `blocking_issues` and `tracking_issue` strictly as issue references for
blockers. Never treat them as runtime evidence.

Second, add the migration module:
- Create `scripts/capability-map-migration.mjs` that exports
`migrateCapabilityMap(map)`.
- For a version 1 input, set `schema_version` to `2`, add `generic: false` and
`blocking_issues: []` to every capability, and rename
`starter_workflow_candidates` to `proofs`.
- Convert the previously selected candidate to `kind: "selected"`, moving
`task_boundary` into `scope`. Convert unselected candidates to `kind:
"candidate"`. Preserve `uses_capabilities[0]` as the `capability` reference.
- Make the function idempotent: return the input unchanged if `schema_version`
is already `2`.
- Create `scripts/capability-map-migration.test.mjs` with tests that confirm
migrating a version 1 map produces a structurally valid version 2 object, and
that migrating twice is a no-op.
- Update `scripts/check.sh` to also run `node --test
scripts/capability-map-migration.test.mjs`.

Third, rewrite `capabilities/capability-map.json`:
- Replace `recurring-draft-responsibility` with a generic capability
`progressive-delegation` (`generic: true`, `state: product_surface_missing`,
protocol-neutral `owner_outcome`).
- Populate `runtime_changes` and `canonical_specs` with the confirmed archived
changes and specs: standing rules, reflection miner, governed artifact
lifecycle, task grants and grant chain, budget hardening, spend kill switch, and
audit artifact store. Verify each change id is in the `## Completed / archived`
section of `openspec/openspine-change-sequence.md` and each spec path exists.
- Populate `blocking_issues` with `#126` (`architecture contract`), `#127` and
`#129` (`execution/review foundations`), `#128` (`scoped evidence/matching`),
`#133` (`proposal-specific evaluation`).
- Keep `selected-gmail-draft` as a shipped vertical capability, distinct from
the generic capability.
- Add proofs referencing `progressive-delegation`: `recurring-gmail-draft`
(`kind: selected`, `selected: true`, `tracking_issue: 130`, scope of one
reviewed connector/account/relationship, reused five-step `proof_sequence`),
`second-protocol-portability` (`kind: portability`, `tracking_issue: 131`),
`whole-responsibility-progression` (`kind: whole_responsibility`,
`tracking_issue: 132`). Leave evidence arrays empty for these because they are
not shipped.
- Keep `task-and-reminder`, `research-and-brief`, `skill-install-proof` as
`kind: candidate` proofs with `selected: false`.
===============================================================================

Task: 2

Follow TDD to add the CI truth rules to the capability map validator. Write
failing tests first in `scripts/capability-map.test.mjs`, then extend
`validateCapabilityMap` in `scripts/capability-map.mjs` to make them pass.

Step 1, update the tests:
- Update the `validMap()` factory and `fixtureRoot()` helper to produce a valid
version 2 map: a generic capability with categorized owner-path tests, a
top-level `proofs[]` array, and fixtures for referenced test/spec/artifact
paths.
- Add a test confirming the generic capability and a proof are distinct objects.
- Add a test confirming exactly one proof has `selected: true`.
- Add a test confirming a proof with `state: shipped` and empty
`owner_path_tests` fails validation.
- Add a test confirming a generic capability marked `wired_into_lyra` with only
`runtime_changes` and no positive-effect and fallback/control owner-path tests
fails validation.
- Add a test confirming a portability proof marked `state: verified` with empty
`conformance_tests` fails validation.
- Add a test confirming `blocking_issues` are rejected wherever runtime evidence
is expected, for example an integer issue placed in `runtime_changes`.
- Keep the existing archived-change, path-existence, and registered-test tests
working against the new fixtures.

Step 2, extend `validateCapabilityMap`:
- Require `schema_version` equal to `2`. Add `proof_in_progress` to
`VALID_STATES`.
- Validate `blocking_issues` entries: `issue` must be an integer, `role` must be
a non-empty string. Reject blocking issues appearing in or substituting for
`runtime_changes`. Reject non-string or integer-like entries in
`runtime_changes`.
- For a capability with `generic: true` and `state: wired_into_lyra`, require at
least one `positive_effect` owner-path test and at least one `fallback` or
`control` owner-path test. Keep the existing rule of "at least one owner-path
test" for non-generic wired capabilities.
- Validate `proofs[]`: exactly one entry with `selected: true`; every
`capability` reference resolves to a known capability id; the selected proof
must have an integer `tracking_issue`, a `proof_sequence` of at least four
steps, and reference a capability with state `product_surface_missing` or
`proof_in_progress`.
- Enforce proof evidence rules: `state: shipped` requires non-empty
`owner_path_tests`; `kind: portability` with `state: verified` requires
non-empty `conformance_tests`; `kind: whole_responsibility` cannot reach `state:
verified` unless the selected proof is `shipped` and the portability proof is
`verified`.
- Reuse the existing path-existence and `hasRegisteredRustTest` checks for every
entry in `owner_path_tests` and `conformance_tests`.
===============================================================================

Task: 3

Update the roadmap renderer in `scripts/capability-map.mjs` to reflect the
corrected maturity structure, and regenerate the public roadmap file.

Renderer changes:
- Update the summary count line to reflect the new states, including any
`proof_in_progress` capabilities. Do not break the existing count format for the
other states.
- Render the generic capability together with its landed substrate. Follow it
with a list of `blocking_issues` grouped by role, using labels `Architecture
contract`, `Execution/review foundations`, `Scoped evidence/matching`, and
`Proposal-specific evaluation`. Render these as issue links. Keep them out of
the "Repository proof" column.
- Render `Selected proof`, `Portability proof`, and `Whole-responsibility
progression` lines for the generic capability. Link each to its tracking issue.
- Apply the public-copy rule: if the selected proof is `shipped` but the
portability proof is not `verified`, render "first shipped proof" language. Do
not claim the capability works across protocols in this case.
- Keep `evidenceMarkdown` showing only archived changes, specs, and named tests
as proof. Never render issue numbers as proof.
- Add a rendering determinism test in `scripts/capability-map.test.mjs`
confirming: blockers appear grouped by role, the three proof lines render with
their issue links, and issue numbers do not appear in the proof column.

Regeneration steps:
- Run `node scripts/capability-map.mjs --write` to regenerate the generated
block in `site/src/content/docs/roadmap.md`.
- Confirm the frontmatter, intro paragraphs, and all content after `<!--
capability-map:end -->` remain byte-for-byte identical.
- Confirm the read-only invocation `node scripts/capability-map.mjs` passes its
staleness check after the write.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

🔗 Related PRs

#14 - Implement harden-approval-and-budgets: WYSIWYS, grant budgets, token hashing (Step 7) [merged]
#16 - Implement backfill-implemented-capability-specs: spec debt repayment [merged]
#19 - Implement implement-artifact-lifecycle-slice: propose/approve/activate (PR-5) [merged]
#50 - feat(store): artifact lineage model and indexed eval-verdict store (D-056) [merged]
#106 - feat(kernel): wire authority-equivalence route selection [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[George-RD]

Restructured into the cohesive roadmap (map #182); original preserved below.

[George-RD]

Design report — #134: can openspine-schemas / openspine-authority natively carry (tenant, principal, contact) as identity dimensions?

Scope. Design report only, no implementation. This is an input to the tenancy fit review (DIRECTION.md: tenancy implementation is fenced post-fit-review; typed owner identity design precedes the assessment). Every recommendation below — including any new TenantId vocabulary — is a post-fit-review recommendation; nothing here is cleared to build now. The report itself is the permitted assessment. Canon consulted first: DIRECTION.md, CONTEXT.md, STORIES.md, plus D-006/D-002/D-174/AD-146/AD-147/AD-060/AD-101/AD-148.

Headline answer

• principal — already native, low violence. First-class typed record with a promotion seam deliberately designed in; one raw-Ulid seam remains at the compose boundary.
• contact (counterparty) — carried natively for routing/persona and, at the schema level, for datum provenance (the typed ProvenanceOrigin vocabulary + grant-caveat mechanics landed in Spec: provenance labels with typed identity #220; runtime enforcement at context assembly/egress is Bind provenance label to typed-identity origin (generalize ProducedBy) #224–Egress origin-closure stage: block cross-identity data deterministically #227, not yet). Contact-target authority is not a grant-level identity binding (see Finding 2): it rides ReviewedActionScope's digest-bound Counterparty dimension, typed as a raw Ulid (not IdentityRef) and compared at the effect boundary rather than MAC-bound into TaskGrant/RootAuthority.
• tenant — not modeled at all (zero references anywhere in crates/). No seam exists — unlike principal. Adding it is structurally low-violence (same shape as the landed user: PrincipalId immutable MAC-bound root binding), but it is tenancy implementation and therefore entirely post-fit-review.

The invariant that governs all three: identity is not authority (D-006). Every dimension is an identity-shaped key the kernel composes a grant FOR; none may carry a capability/route/grant field. Any proposal that makes a dimension authority-bearing is out of bounds by canon.

---

Current structure (grounded)

Principal dimension — openspine-schemas (spec #197, AD-146, D-006):

• Principal (principal.rs): { id, identity_id, is_owner, schema_version } — identity fields only; deny_unknown_fields structurally rejects any injected authority key (tested). v1 enforces exactly one principal (is_owner).
• PrincipalId (ids.rs): #[serde(transparent)] newtype over Ulid. Wire form byte-identical to Ulid::to_string(), so a TaskGrant MAC that sealed a stringified principal Ulid verifies unchanged after user was retyped to PrincipalId (D-005). "owner"/"kernel"/i64 shapes are unrepresentable by construction (compile_fail docs).
• OwnerPrincipal (owner.rs, spec Spec: Typed Owner Identity #197, D-002): single typed source of truth for the bootstrapped owner — { principal_id: PrincipalId, identity_id, telegram_binding: i64 (private) }. The Telegram channel binding is reachable only via telegram_binding() so no generic kernel path reads the raw channel id.

Contact (counterparty) dimension — openspine-schemas:

• Identity (identity.rs, PRD §5.3): entity knowledge only — identifiers[] (hashed values), relationships[] (RelationshipKind), entity_type. Explicitly no authority field (D-006).
• IdentityRef (ids.rs, spec Spec: provenance labels with typed identity #220/Introduce ProvenanceOrigin and IdentityRef typed vocabulary #222): sibling of PrincipalId under the identical transparent-newtype discipline; names whose data an item is, grants nothing.
• Contact routing/persona: RouteActorWhen.relationship / channel_trust / identity_confidence_min and RouteWhen.channel_account (route.rs); persona binding (persona_binding.rs, AD-136) derives from the resolved relationship, never an agent claim.
• Relationship-scoped disclosure: DisclosurePolicy keyed (relationship × disclosure-class) (disclosure_policy.rs, AD-146).
• Reviewed contact-target scope: ReviewedActionScope (reviewed_scope.rs) carries a Counterparty(Ulid) dimension plus ReviewedTargetScope{ refs } and a TargetDigest, compared deterministically against the resolved action context (binding_is_valid / compare). This is the mechanism behind the Ship recurring Gmail drafts as the first complete delegation proof #130 "one reviewed connector/account/relationship" scope — but note the counterparty value is a raw Ulid, not IdentityRef.

Provenance origin (the identity axis of egress) — openspine-schemas (spec #220, D-174):

• ProvenanceOrigin (provenance.rs): closed, internally-tagged enum — Owner{principal: PrincipalId} | Counterparty{identity: IdentityRef} | System{}. Closed (never #[non_exhaustive]) so every exhaustive match breaks loudly if an origin kind is added. System {} is a struct variant specifically to keep deny_unknown_fields fail-closed. Note this is datum provenance — whose data an item is — not who a grant may act toward.

Authority carriage — openspine-schemas grant chain (AD-101/AD-148) + openspine-authority:

• TaskGrant.user: PrincipalId and RootAuthority.user: PrincipalId are immutable, MAC-bound root identity fields (grant.rs, grant_chain.rs). RootAuthority's doc is explicit: "Immutable root authority + routing/identity bindings authenticated as the chain base commitment. Every field gate or routing trusts that is fixed for the chain lifetime belongs here." There is no counterparty/IdentityRef field on TaskGrant or RootAuthority — the only identity a grant is composed FOR is the owner principal.
• Two kinds of dimension carriage already coexist, and the distinction is the crux of the tenant recommendation:
  • Immutable identity/routing scope ⇒ a RootAuthority field, MAC-bound from root issuance, resealed at mint. Examples: user, route_id, capability_pack_id, and the dormant thread_id: Option<String>. canonical_bytes omits thread_id/allowed_egress_classes when None/empty so legacy MACs stay byte-identical, then a populated value changes the committed bytes and must be resealed.
  • Append-only narrowing allowlist ⇒ a chain caveat, intersected across hops, empty ⇒ provably closed, never widens. Examples: EgressClassAllowlist (AD-060) and ProvenanceLabelAllowlist{origins} (D-174). D-174 gave provenance origin no root field because it is a narrowing allowlist, not a base identity scope.
• Composition (compose.rs) is a pure merge; AuthorityInput carries identity: &IdentityResolution and principal_id.

---

Finding 1 — Generic capability (protocol-neutral identity-dimension model)

The protocol-neutral capability is: carry (tenant, principal, contact) as typed identity dimensions that key authority composition and provenance, with no dimension ever becoming authority (D-006).

The repo already has a generic discipline for identity dimensions, not a per-dimension hack:

1. transparent Ulid newtype (PrincipalId, IdentityRef) ⇒ MAC byte-stable across retype, raw strings/i64 unrepresentable;
2. closed, internally-tagged enums (ProvenanceOrigin) ⇒ exhaustive matches break loudly on a new arm;
3. deny_unknown_fields everywhere ⇒ fail-closed against injected authority keys;
4. kernel-minted, no worker-set raw string (AD-032/AD-121);
5. two carriage shapes with a clear rule: immutable identity scope ⇒ MAC-bound root field; narrowing allowlist ⇒ append-only caveat.

principal and contact are substantially carried by this discipline — but neither is fully typed to the discipline end-to-end (both still have raw-Ulid seams, below), and tenant is absent with no seam. So the generic capability exists and is genuinely reusable; its coverage is 2-of-3 dimensions with two open typed-identity seams. Adding tenant is an application of the existing discipline (a TenantId newtype + a root-field carriage decision), not a new abstraction — the "without violence" path, but post-fit-review.

Finding 2 — Selected proof evidence (what is landed and proven)

The landed evidence is schema-level, not end-to-end enforcement — the owner-principal + counterparty-origin path at the type/grant-mechanics layer:

• Spec: Typed Owner Identity #197 (landed): PrincipalId, Principal, OwnerPrincipal. Tests pin the D-006 contract (principal serializes identity fields only; deny_unknown_fields rejects an injected capability_pack_id; owner aggregate carries no authority key) and the MAC-survives-retype claim (compile_fail on user = String). Proves the owner principal threads as an immutable MAC-bound root scope.
• Spec: provenance labels with typed identity #220/Introduce ProvenanceOrigin and IdentityRef typed vocabulary #222 (landed, compile-time half only): IdentityRef, closed ProvenanceOrigin, ProvenanceLabelAllowlist caveat with append-only intersection (grant_chain::effectively_allows_provenance_label), DisclosurePolicy relationship×class. provenance.rs is explicit that this is the compile-time half of the provenance hybrid: it lands the typed origin vocabulary and the grant-caveat mechanics only. The runtime half — kernel briefcase packing deriving each item's origin and the egress gate consulting it deterministically — lands in the later egress/briefcase tickets (Bind provenance label to typed-identity origin (generalize ProducedBy) #224–Egress origin-closure stage: block cross-identity data deterministically #227), not here. So this is schema-level evidence that the counterparty origin has a typed, MAC-narrowable representation; it is not an end-to-end demonstration that contact provenance is enforced at context assembly or egress.

Two seams keep the proof partial — do not overstate:

1. principal compose seam. The typed principal seam is proven at the grant/MAC boundary but not threaded through composition: AuthorityInput.principal_id: Ulid (compose.rs:51) and IdentityResolution.principal_id: Option<Ulid> (identity.rs:125) are still raw Ulid.
2. contact-target authority is NOT a grant-level identity binding. TaskGrant/RootAuthority carry no IdentityRef counterparty field. The Counterparty datum-provenance origin is only about whose data egresses, not who a grant may act toward. Reviewed contact-target authority is carried by ReviewedActionScope's digest-bound Counterparty dimension, compared deterministically at the effect boundary — a real landed mechanism, but (a) not part of the MAC-bound grant identity, and (b) typed as a raw Ulid (ReviewedScopeValue::Counterparty(Ulid)), not IdentityRef. Therefore "contact is carried natively" is true for routing/persona/provenance and for reviewed-scope comparison, but contact-target authority at the grant layer is unproven and, if the fit review wants it MAC-bound, needs an explicit RootAuthority binding.

Finding 3 — Portability evidence (is the design secretly single-owner / single-tenant / Telegram-specific?)

Positive (portable by design):

• AD-146 states the principal seam makes multi-principal promotion "additive, not a rewrite"; "a counterparty with rich standing rules is still not a principal." Spec: Typed Owner Identity #197 tests pin the serialized contract so promotion is checkable.
• The immutable-root-binding pattern is proven for adding a new base scope: thread_id was added to RootAuthority/canonical_bytes as a dormant Option, omit-when-None for legacy MAC stability, resealed at mint. A tenant scope is the same operation. Separately the narrowing-caveat pattern is proven twice (AD-060 egress class; D-174 provenance origin), and D-174 line 4177 says a future principal-facing visibility class (customer-visible/staff/owner) "can be added without redesigning provenance." Both carriage shapes have precedent, so a third identity axis is portable — provided the right shape is chosen.
• Transparent newtypes ⇒ MAC byte-stability across retype is a general property, not owner-specific.

Negative (genuinely specific / not yet demonstrated):

• tenant: no dimension and no seam. Zero tenant references in crates/. The real gap — nothing was pre-designed, whereas principal was.
• contact-target authority is not grant-bound and not typed. As Finding 2: the reviewed Counterparty dimension is a raw Ulid outside the grant MAC. A second protocol reusing contact-target scope would inherit an untyped, non-MAC-bound binding.
• Telegram-specificity in the owner binding. OwnerPrincipal.telegram_binding: i64 is a single-channel scalar (D-002 keeps it private but it is Telegram-only). IdentifierKind = {TelegramUserId, Email, WhatsappNumber} and MatchedIdentifierType are closed — a second protocol (WhatsApp, Prove progressive delegation is portable across communication protocols #131) extends these enums additively (loud), but the owner channel binding is one scalar, not a set.
• Hard single-owner invariant. v1 enforces exactly one is_owner (AD-146) — deliberate, not accidental.
• No second protocol has exercised the identity path. The WhatsApp connector is built during Bell's spike, never before (DIRECTION.md). Portability is designed but not demonstrated — no second-protocol conformance evidence exists today (the distinction Prove progressive delegation is portable across communication protocols #131 tracks). Per the ticket's rule, this axis may not be marked "works across protocols."

---

Required schema changes (recommendations — no implementation; all post-fit-review where tenancy is involved)

principal (completes the landed proof; low violence — a typed-identity correctness change, not tenancy):

• Retype AuthorityInput.principal_id: Ulid → PrincipalId (compose.rs) and IdentityResolution.principal_id: Option<Ulid> → Option<PrincipalId> (identity.rs). MAC is already byte-stable across this retype (proven by Spec: Typed Owner Identity #197), so risk is compile-surface only. Closes the one open principal seam.
• Relaxing the exactly-one-owner invariant (multi-principal households, OQ-4) stays behind the fit review — do not change Principal.is_owner semantics now.

contact (correct the overstatement; two distinct changes):

• Typed-identity discipline: retype ReviewedScopeValue::Counterparty(Ulid) → IdentityRef so the reviewed contact-target dimension matches the PrincipalId/IdentityRef discipline (a correctness change parallel to the principal retypes).
• Grant-level contact-target binding: if the fit review wants a grant scoped to act toward a specific reviewed counterparty to be MAC-bound (not merely compared at the effect boundary), that requires an explicit immutable IdentityRef binding on RootAuthority (same shape as user), resealed at mint. Treat this as currently unproven and a fit-review decision, not a done capability. Second-protocol identity resolution additionally needs additive IdentifierKind/MatchedIdentifierType variants (closed-enum extension, loud and safe).

tenant (new dimension — post-fit-review only; do not build any part now):

1. A future typed TenantId newtype in ids.rs, sibling of PrincipalId/IdentityRef (transparent Ulid, deny_unknown_fields). This is tenancy implementation and is fenced — it lands only after the fit review, not now.
2. Carriage (recommendation for the review): a tenant scope is an immutable identity scope, so it belongs on RootAuthority, MAC-bound from root issuance — not a caveat. A caveat has append-only narrowing semantics; a tenant is not something a child narrows, it is the fixed base commitment answering "whose kernel/tenant does this whole grant belong to," exactly like user: PrincipalId. Concretely: add tenant_id (likely Option<TenantId> for dormant/legacy compatibility) to RootAuthority, thread it through from_grant/canonical_bytes with the omit-when-None backward-compat the landed thread_id uses, and reseal at mint. The AD-148 desync rule does not forbid a new root field — it forbids mutating an already-sealed root/subgrant; every new root commitment updates canonical_bytes and reseals at mint time, as allowed_egress_classes and thread_id already did. Modeling tenant as an inferred/later caveat would be the actual mistake: it would leave the scope mutable and unbound at issuance.
3. Bell is instance-per-tenant in v1 (DIRECTION.md) ⇒ kernel tenancy is consolidation, not launch-blocking. The negative decision-log notes (D-020 single-owner store; bulkhead pools deferred as multi-tenant-only) mean premature tenant carriage would contradict settled scope. The review decides whether same-kernel multi-tenancy is a real target; if it is, the tenant scope lands as a MAC-bound root field.

Bottom line for the fit review

principal is carried natively with low violence: the proof is complete except for two Ulid → PrincipalId retypes at the compose boundary. contact is carried natively for routing/persona; contact datum provenance has a landed typed vocabulary + grant-caveat mechanics (#220) but its runtime enforcement is future (#224–#227), so it is schema-level evidence, not an end-to-end proof. Reviewed contact-target scope is a landed digest-bound mechanism — but that dimension is a raw Ulid (not IdentityRef) and is not a MAC-bound grant identity, so grant-level contact-target authority is unproven and is a fit-review decision. tenant is genuinely absent and unseamed; adding it is structurally low-violence (same shape as user: PrincipalId, via the landed thread_id root-field precedent, not a narrowing caveat), but it is tenancy implementation and therefore entirely post-fit-review. Keep every dimension identity-only (D-006).

[George-RD]

Correction note (report above edited in place). Three refinements after review:

1. Fence: removed the earlier claim that a TenantId newtype was "safe to add pre-fit-review." DIRECTION fences all tenancy implementation until the fit review — the report is the assessment; every tenant/root-field change is a post-review recommendation only.

2. Contact-target authority de-overstated: the original said contact "needs no change / is carried natively." Corrected: TaskGrant/RootAuthority carry no IdentityRef counterparty field, and ProvenanceOrigin::Counterparty is only datum provenance. Reviewed contact-target authority rides ReviewedActionScope's digest-bound Counterparty dimension — a real landed mechanism, but it is a raw Ulid (not IdentityRef) and is compared at the effect boundary rather than MAC-bound into the grant. So grant-level contact-target authority is unproven; making it MAC-bound is a fit-review decision (explicit RootAuthority IdentityRef binding), and retyping ReviewedScopeValue::Counterparty(Ulid) → IdentityRef is the typed-identity correctness change.

3. Provenance evidence is schema-level, not end-to-end: provenance.rs is explicit that Spec: provenance labels with typed identity #220 landed only the compile-time half (typed ProvenanceOrigin vocabulary + grant-caveat mechanics). The runtime half — kernel briefcase packing deriving origin and the egress gate consulting it — lands in Bind provenance label to typed-identity origin (generalize ProducedBy) #224–Egress origin-closure stage: block cross-identity data deterministically #227, not yet. Finding 2 now frames Spec: provenance labels with typed identity #220 as schema-level evidence, not an end-to-end selected proof of contact provenance enforcement.

[George-RD]

Coordinator: accepting the design report above as this ticket's deliverable (report-only, per AC). One timeline correction: the runtime half of provenance IS landed as of this run — #224 (PR #251), #225 (PR #256), #227 (PR #267, origin-closure egress stage, CLAIM-44) — so the report's 'runtime briefcase/egress enforcement not yet' reading applies only to the pre-run tree it analyzed; the schema-level findings and the (tenant, principal, contact) recommendations stand. Findings feed the Bell fit review (tenancy is fenced). Closing.