onto-mcp 0.4.9 → 0.4.10

package/.onto/authority/supported-models.yaml

@@ -0,0 +1,27 @@
+# Supported model registry — authority SSOT for selectable LLM models.
+#
+# Only models whose support has been verified by a benchmark (a benchmark record
+# shows the model completing a pipeline run end to end) may be listed here.
+# settings.json model selection is validated against this registry by the
+# supported-model gate (assertSettingsModelsSupported): at the reconstruct live
+# execution boundary (real provider calls) and by the `check:supported-models`
+# (G7) guard on the committed config (every seat). Review-side runtime
+# enforcement is a noted follow-up, so the runtime gate is wired on the
+# reconstruct live path only today. A (provider, model) pair not listed here is
+# rejected fail-loud at those gate points. Settings resolution itself is a pure
+# projection and does not enforce this gate.
+#
+# To add a model: run the benchmark, confirm a completed run, then add an entry
+# citing the benchmark record under benchmark_evidence_refs. Curated by humans;
+# the citation is the evidence, the entry is the authority.
+schema_version: "1"
+supported_models:
+  - provider: openai
+    model: gpt-5.5
+    verified_at: "2026-06-13"
+    benchmark_evidence_refs:
+      - development-records/benchmark/reconstruct-pipeline-live-20260613.json
+    notes: >-
+      Completed a full reconstruct pipeline run in the live medium baseline
+      (1 of 6 attempts completed end to end); support verified. Performance
+      evidence is PRELIMINARY in that record — support, not a performance claim.

package/.onto/processes/reconstruct/ontology-seeding-and-maturation-design.md

@@ -813,8 +813,10 @@ is used as an implementation contract.
 
 | Artifact | Registry status | Owner | Role |
 |---|---|---|---|
-| `maturation-baseline.yaml` | active registry | runtime | L0-L4 matrix from seed, CQs, limitations, and the validated seeding reconstruct record |
+| `maturation-baseline.yaml` | active registry | runtime | **[immutable seed-derived baseline]** L0-L4 matrix from seed, CQs, limitations, and the validated seeding reconstruct record |
 | `maturation-baseline-validation.yaml` | active registry | runtime | proves baseline rows derive from validated seed, purpose, CQ/proof, handoff authorities, and the source seeding record ref/hash |
+| `baseline-actionability-matrix.yaml` | active registry | runtime | **[immutable zero-delta baseline matrix]** baseline static/kinetic/dynamic actionability matrix consumed by question-frontier authoring; distinct from the mutable current `actionability-matrix.yaml` |
+| `baseline-actionability-matrix-validation.yaml` | active registry | runtime | proves the baseline matrix derives from the validated maturation baseline with zero delta before question-frontier consumption |
 | `maturation-promotion-request.yaml` | planned registry | runtime | durable request authority for maturation execution or planned gate promotion |
 | `maturation-promotion-request-validation.yaml` | planned registry | runtime | proves request id, trigger refs, requested gates, and replay authority before promotion-readiness evaluation |
 | `maturation-runtime-capability-profile.yaml` | planned registry | runtime | records runtime-observed writer, validator, predicate, and activation capability for planned maturation gates |
@@ -838,7 +840,7 @@ is used as an implementation contract.
 | `maturation-answer-claims-validation.yaml` | active registry | runtime | answer claim refs, evidence, and limitation closure |
 | `ontology-expansion.yaml` | active registry | host LLM author | ontology additions/refinements/deferred/rejected changes |
 | `ontology-expansion-validation.yaml` | active registry | runtime | concept economy, ref closure, surface coverage, and regression guards |
-| `actionability-matrix.yaml` | active registry | runtime | static/kinetic/dynamic by 7D and purpose element, with L0-L4 levels |
+| `actionability-matrix.yaml` | active registry | runtime | **[mutable current projection]** static/kinetic/dynamic by 7D and purpose element, with L0-L4 levels |
 | `actionability-matrix-validation.yaml` | active registry | runtime | proves matrix rows derive from validated baseline and active maturation artifacts; promoted source-delta/source-impact authorities are consumed when activated |
 | `maturation-convergence-ledger.yaml` | active registry | runtime | append-only round ledger of material question closure, trace/audit-only closure, round source-observation delta refs, and remaining frontier |
 | `maturation-convergence-ledger-validation.yaml` | active registry | runtime | proves every blocker/high question is closed, carried forward, or blocked with refs before continuation is projected |
@@ -1476,6 +1478,33 @@ valid evidence cluster, proof, or user confirmation. An answer may be
 `partially_answered` only when the answered portion has positive support and the
 remaining gap is represented as a limitation or frontier question.
 
+Implementable `answer-support-judgment.yaml` shape (target design until the judge
+runtime stage is implemented):
+
+```yaml
+schema_version: "1"
+session_id:
+created_at:
+round_id:
+judgments:
+  - judgment_id:
+    evidence_cluster_ref:          # a validated answer-support-ledger evidence cluster
+    evidence_ref:                  # one evidence ref of that cluster
+    supports: supported | not_supported
+    rationale_ref:                 # bounded judge rationale
+```
+
+An independent judge role, distinct from the answer-support-ledger author, records
+one bounded `supports` verdict per cited evidence ref. The judge does not decide
+sufficiency: a `convergent_source_evidence` answer claim validates only when at
+least two independent evidence refs each carry a `supports: supported` judgment
+with contradictions still bounded, and runtime aggregates that count. Author and
+judge are separated structurally because the judgment is a distinct authored
+artifact attributed to its own pipeline stage, not a field the support author can
+fill. This hardening narrows only the "evidence implies the answer" residue for
+convergent source evidence; the existing count, independence, and contradiction
+checks are unchanged.
+
 #### Maturation Closure Dispositions
 
 Not every inspected issue should become ontology meaning. Maturation therefore
@@ -2421,12 +2450,13 @@ runtime, user, external, or domain-standard authority, maturation projects
 freshness concerns, or out-of-scope questions, those rows are closed in the
 convergence ledger.
 
-This gives maturation two separate stop signals:
+This gives maturation two separate stop signals, each an explicit projection of
+the convergence conditions above (not a second source of truth):
 
-| Stop signal | Meaning |
-|---|---|
-| Matrix closure | every material static/kinetic/dynamic x seven-dimension row is L4 or limitation-backed outside the claim |
-| Re-question closure | a fresh frontier generated from the current artifacts yields no new material question that can change the actionability claim |
+| Stop signal | Projects which convergence conditions | Meaning |
+|---|---|---|
+| Matrix closure | Static/kinetic/dynamic actionability + L4 matrix + Material gap closure | every material static/kinetic/dynamic x seven-dimension row is L4 or limitation-backed outside the claim |
+| Re-question closure | Re-question convergence | a fresh frontier generated from the current artifacts yields no new material question that can change the source-derived purpose adequacy frame |
 
 Both are required before `actionable_ready`; `actionable_limited` may exclude
 named rows only when the convergence ledger explains the limitation and the
@@ -3083,90 +3113,13 @@ Implementation file map:
 | MCP/API projection | `src/core-api/reconstruct-api.ts`, `src/mcp/server.ts` |
 | active docs and user-facing guide | this document, `operational-ontology-seed-contract.md`, `README.md`, `IMPLEMENTATION_MAP.html` |
 
-Current implementation has promoted seeding source-purpose authority,
-pre-seed authoring readiness, compact selected-purpose prompt projection, direct
-compact source-scout prompt projection for source-observation directive,
-source-purpose, and candidate-inventory authoring, and the registry-backed
-first-pass maturation authorities: baseline, baseline actionability matrix,
-question frontier, closure frontier, answer support, answer claims, ontology
-expansion, current actionability matrix, maturation source-delta, convergence,
-continuation decision, and explicit proof-authority boundaries. Multi-round
-source-observation delta and source-observation re-entry validation are active
-for frontier-triggered observations before they re-enter prompt/context semantic
-authoring or answer-support consumption. The optional `actionable-ontology.yaml`
-projection is active for `actionable_limited` or `actionable_ready` continuation
-states and is validated as a runtime projection of existing seed, expansion,
-matrix, convergence, continuation, and proof boundary authorities.
-Promoted same-request resume is active for authored artifacts only when reuse
-provenance matches the current request, source/profile/domain
-snapshot, source-safety/scout/lineage validation, and seed-authoring readiness
-validation once those upstream authorities exist. Run-control resume rows record
-the provenance match policy and check refs; semantic quality remains revalidated by
-the downstream artifact validators.
-`seed-authoring-readiness-validation.yaml` now also records
-`deterministic_gate_scope: pre_seed_closure_only` and fails when the readiness
-artifact omits the required boundary notes that keep deterministic closure
-separate from semantic ontology adequacy. It also validates
-`max_round_exhaustion_interpretation` so `max_round_exhausted` is not collapsed
-into one generic state: a selected-purpose closure can remain
-`sufficient_for_claim_scope`, while an exhausted open frontier projects
-`insufficient_for_claim_scope` plus `exhausted_with_open_frontier`.
-Ontology-domain category rows remain diagnostic unless the selected purpose
-actually has a closure row for that category. They can expose modeling gaps, but
-they must not block seed authoring just because a domain profile contains a
-category that the selected source purpose did not require.
-The first source frontier now has an actor-action-state scout policy: for
-`round-1`, valid `SourceScoutPack` actor/action/state coverage gaps are sent as
-inventory-only exploration candidates, and runtime may add up to three
-unobserved code/document refs when the author returns an empty frontier. This
-policy chooses exploration priority only; it does not create purpose elements or
-ontology claims.
-`source-scout-pack.yaml` remains a latest-current scout projection alias.
-Pre-seed source-purpose, candidate-inventory, SeedAuthoringReadiness, and seed
-reuse provenance consume immutable `source-scout-pack.pre-seed.yaml` and
-`source-scout-pack-validation.pre-seed.yaml` snapshots. After maturation source
-lineage refresh, runtime emits `source-scout-pack.post-maturation.yaml` and
-`source-scout-pack-validation.post-maturation.yaml` so later audit surfaces can
-distinguish the exact consumed snapshot from the latest-current alias.
-The contract registry treats those validation snapshots as snapshot-scoped
-active gate outputs, and the SeedAuthoringReadiness validator consumes the
-pre-seed validation snapshot as its concrete source scout authority. Runtime
-identity checks compare the validation artifact to its concrete sibling snapshot
-ref, not only to `source-scout-pack.pre-seed.yaml` by basename, so copied
-same-basename snapshots from another session do not satisfy the pre-seed
-authority boundary.
-Because the post-maturation snapshot is emitted after pre-handoff readiness,
-`handoff-decision-validation.yaml` projects its gate as `not_applicable` during
-the seed handoff. Runtime closes the later lifecycle boundary with
-`post-maturation-gate-projection-validation.yaml`, which evaluates
-`source_scout_pack_post_maturation_gate` from the post-maturation snapshot refs
-before final-output and record consumption. That projection also requires the
-post-maturation validation artifact and SourceScoutPack snapshot to be concrete
-same-session siblings, not only same-phase basenames.
-Prompt payloads now compact `exploration-synthesis.yaml` before source-frontier,
-source-purpose, and candidate-inventory authoring. The projection preserves gap
-ids, lens ids, descriptions, requested source refs, and evidence observation ids,
-while omitting full `evidence_refs` objects to reduce prompt size without
-changing artifact authority.
-Mixed targets currently record `member_scoped_composite` scout scope as a
-phase-1 limitation with no signal rows. This preserves member-scope truth
-without claiming aggregate scout-enabled closure before a member-scoped scout
-contract is promoted.
-Seed authoring now has a focused repair loop: when the first
-`ontology-seed.yaml` fails validation, runtime preserves the invalid seed and
-validation sidecars as `ontology-seed-repair-1.input*.yaml`, asks the seed author
-to revise only the validation-derived repair sections, rewrites
-`ontology-seed.yaml`, and requires the repaired seed validation to pass before
-downstream maturation consumes it.
-Provider timeout recovery is staged and bounded. Source-purpose timeout retries
-with a smaller LLM prompt that keeps the same `SourcePurposeCandidates` output
-contract. Seed timeout first retries a smaller `OntologySeedMinimalKernel`
-prompt; if that also times out, the run fails closed because runtime must not
-author semantic ontology seed content. Claim realization and competency-question
-authoring receive compact seed summaries and allowed-claim projections, and
-competency-question timeout recovery may project deterministic coverage
-questions from allowed claims and domain competency rows so downstream
-validators can prove coverage or preserve limitations.
+Current implementation status — which authorities are promoted, and the
+resume/timeout/scout/repair/snapshot behavior — is owned by
+`reconstruct-contract-registry.yaml` and surfaced in `IMPLEMENTATION_MAP.html`.
+This contract intentionally does not restate present-tense implementation status
+(it goes stale the moment runtime changes and nothing consumes it for dispatch).
+A point-in-time snapshot of the prior recomposition status is isolated at
+`development-records/archive/20260614-reconstruct-maturation-design-relocated-narrative.md` §A.
 
 Required test path for each implementation slice:
 
@@ -3464,58 +3417,15 @@ linked from the registry, this recomposition may claim only run-level governance
 not release health, rollback, quota, resource-exhaustion, or post-incident
 program completeness.
 
-## 16. Completion Definition For This Recomposition
-
-The recomposition is implemented when a fresh reconstruct run against a real
-target produces:
-
-1. `reconstruct-run-control.yaml` and validation proving session ownership,
-   idempotency fingerprinting, active-attempt lock ownership, duplicate-start
-   diagnostics, and observed file-hash write checkpoints, or a bootstrap
-   diagnostic when run-control validation fails before trust can be established,
-2. material-aware source observations,
-3. source-purpose candidates, purpose candidate validation, and purpose
-   confirmation validation when required,
-4. candidate inventory and disposition with purpose-element and actionability
-   surface mapping,
-5. `ontology-seed.yaml` using the active seed contract,
-6. source-derived purpose and purpose adequacy evidence closure,
-7. user confirmation for inferred purpose when direct source purpose is absent,
-8. deterministic validation artifacts for every gate,
-9. canonical candidate-disposition, competency-question, assessment, and
-   handoff-validation authorities, including diagnostic or claim-based P3
-   competency-question disposition when ontology domain competency admission is present,
-10. phase-scoped material admission rows and validation for pre-seed purpose
-    elements, literal material-value rows, post-CQ domain competency rows, and
-    maturation reassessment rows when each phase is applicable,
-11. active source-frontier dependency validation, round source-observation
-   delta/re-entry validation, and a validated session lineage index that
-   preserves each newly observed source before answer-support consumption,
-12. registry ref/hash plus active contract ref/hash, source profile migration,
-   lens judgment, concrete gate-instance, validator, reference-standard,
-   pattern-catalog URI/snapshot, and readiness-projection snapshots,
-13. separate process-completion and seed-validity reporting,
-14. final output that explains `OntologySeed` content, source-derived purpose,
-    purpose adequacy frame, seed iteration readiness, maturation frontier, and
-    limitations, and
-15. a reconstruct record whose artifact refs are the source of truth,
-16. claim projection rows and validation for status/result/MCP/API surfaces when
-    those surfaces claim readiness, actionability, or material-kind support,
-    citing `target-material-profile-validation.yaml` and the immutable
-    pre-publication run-control checkpoint, and final-output claim sections that
-    cite the canonical refs without restating pre-publication claim values,
-17. source-safety authority rows and validations when observed source lifecycle,
-    redaction, privacy, or authorization affects prompt/context use, plus planned
-    mutable-vocabulary authority rows after registry promotion when external
-    standards, provider/framework terms, or profile-owned facets affect a
-    material claim,
-    and
-18. registry-verification evidence for any present-tense active, promoted,
-    current, implemented, or executable claim.
-
-The full maturation stage is implemented when the required target artifacts are
-promoted into the registry and a fresh run can continue from that seed and
-produce:
+## 16. Maturation Completion Criteria
+
+Seeding completion criteria are consolidated in §5.1. The one-time recomposition
+completion checklist (seeding portion) is isolated at
+`development-records/archive/20260614-reconstruct-maturation-design-relocated-narrative.md` §B;
+it is historical and is not current authority.
+
+Maturation is complete when the required target artifacts are promoted into the
+registry and a fresh run can continue from that seed and produce:
 
 1. valid reconstruct run-control ownership or resume authorization for the
    maturation attempt,

package/.onto/processes/reconstruct/reconstruct-contract-registry.yaml

@@ -1229,6 +1229,14 @@ planned_artifact_authorities:
     authority_ref: required-when-evaluation-validation.yaml
     validation_ref: null
     activation_condition: registry_predicate_evaluator_runtime_is_implemented
+  answer_support_judgment:
+    authority_ref: answer-support-judgment.yaml
+    validation_ref: answer-support-judgment-validation.yaml
+    activation_condition: answer_support_judge_runtime_is_implemented
+  answer_support_judgment_validation:
+    authority_ref: answer-support-judgment-validation.yaml
+    validation_ref: null
+    activation_condition: answer_support_judge_runtime_is_implemented
 
 validation_gate_catalog:
   - gate_id: reconstruct_run_control_gate
@@ -1388,6 +1396,12 @@ planned_validation_gate_catalog:
     validation_artifact_ref: required-when-evaluation-validation.yaml
     required_when: always
     activation_condition: registry_predicate_evaluator_runtime_is_implemented
+  - gate_id: answer_support_judgment_gate
+    validation_artifact_ref: answer-support-judgment-validation.yaml
+    required_when: answer_support_judgment_required
+    activation_condition: answer_support_judge_runtime_is_implemented
+    activation_prerequisites:
+      - answer_support_ledger_validation_is_valid
 
 required_when_predicate_family_catalog:
   - predicate_family_id: frontier_observation_use_by_downstream_artifact
@@ -1515,6 +1529,20 @@ required_when_predicate_catalog:
     truth_expression: "source_observation_delta_validation.validation_status == valid and answer_support_ledger_refs_delta_observation_ids"
     unknown_projection: not_applicable
     explanation_template: "Answer support ledger cites observation ids from a frontier-triggered observation delta."
+  - predicate_id: answer_support_judgment_uses_frontier_observation
+    predicate_family_id: frontier_observation_use_by_downstream_artifact
+    gate_instance_scope: per_round
+    downstream_artifact_ref: answer-support-judgment.yaml
+    downstream_validation_ref: answer-support-judgment-validation.yaml
+    input_authority_refs: [rounds/<round-id>/source-observation-delta.yaml, rounds/<round-id>/source-observation-delta-validation.yaml, answer-support-judgment.yaml]
+    truth_expression: "source_observation_delta_validation.validation_status == valid and answer_support_judgment_refs_delta_observation_ids"
+    unknown_projection: not_applicable
+    explanation_template: "Answer support judgment cites observation ids from a frontier-triggered observation delta."
+  - predicate_id: answer_support_judgment_required
+    input_authority_refs: [answer-support-ledger.yaml, answer-support-ledger-validation.yaml]
+    truth_expression: "artifact_exists(answer-support-ledger.yaml) and answer_support_ledger_has_convergent_source_evidence_cluster"
+    unknown_projection: not_applicable
+    explanation_template: "A judge confirmation is required when answer support uses convergent source evidence."
   - predicate_id: maturation_answer_claims_use_frontier_observation
     predicate_family_id: frontier_observation_use_by_downstream_artifact
     gate_instance_scope: per_round
@@ -2663,11 +2691,20 @@ validator_records:
       - maturation-question-frontier-validation.yaml
       - ontology-seed.yaml
       - reconstruct-contract-registry.yaml
+    conditional_input_authority_refs:
+      - artifact_ref: answer-support-judgment-validation.yaml
+        activation_condition: answer_support_judge_runtime_is_implemented
+        consumed_for:
+          - require_convergent_source_evidence_claims_to_have_two_independent_judge_confirmed_supports
     validation_obligations:
       - validate_answer_claim_question_refs
       - validate_support_mode_against_valid_evidence_cluster_or_authority
       - require_partial_answers_to_have_limitation_or_frontier_refs
       - validate_answer_claim_surface_dimension_and_purpose_element_refs
+    conditional_validation_obligations:
+      - obligation_id: require_convergent_source_evidence_claims_to_have_two_independent_judge_confirmed_supports
+        activation_condition: answer_support_judge_runtime_is_implemented
+        input_authority_refs: [answer-support-judgment-validation.yaml]
     output_ref: maturation-answer-claims-validation.yaml
   - validator_id: ontology-expansion-validator
     gate_ids: [ontology_expansion_gate]
@@ -2906,6 +2943,18 @@ validator_records:
     output_ref: handoff-decision-validation.yaml
 
 planned_validator_records:
+  - validator_id: answer-support-judgment-validator
+    gate_ids: [answer_support_judgment_gate]
+    validator_version: 1
+    input_authority_refs:
+      - answer-support-judgment.yaml
+      - answer-support-ledger-validation.yaml
+      - reconstruct-contract-registry.yaml
+    validation_obligations:
+      - validate_judgment_refs_resolve_to_answer_support_ledger_clusters_and_evidence
+      - require_supports_enum_for_each_judgment
+      - require_rationale_ref_for_each_judgment
+    output_ref: answer-support-judgment-validation.yaml
   - validator_id: maturation-promotion-request-validator
     gate_ids: [maturation_promotion_request_gate]
     validator_version: 1

package/.onto/processes/reconstruct/reconstruct-execution-ux-contract.md

@@ -19,6 +19,11 @@ No standalone HTML, web UI, or dashboard is required for this contract. MCP and
 CLI hosts should render the same information from runtime status/result payloads
 and reconstruct artifacts.
 
+This contract owns the generic reconstruct run UX. The material-kind-specific
+delta (detected `target_material_kind`, observation counts by material kind,
+unsupported/out-of-scope material) is owned by `target-material-kind-contract.md`
+§9 and is layered onto the surfaces below.
+
 ## 2. Opening Brief
 
 At run start, the host should show a compact opening brief before expensive

package/.onto/processes/reconstruct/source-profile-contract.md

@@ -186,7 +186,12 @@ promote that facet into a permanent profile rule during the same run.
 ## 6. Mixed Material Rule
 
 `mixed` is a public `TargetMaterialKind` value, but it is not a material parser.
-Runtime must choose one of these behaviors before observation:
+Reconstruct exposes these three of the four lexicon-defined mixed behaviors as
+runnable observation behaviors; the fourth, `reserved_future`, is a non-runnable
+vocabulary state and is not a reconstruct-runnable path (so it is not in the
+runnable list below). Runtime must choose one of the three runnable behaviors
+before observation (full enum authority: `core-lexicon.yaml#TargetMaterialKind`
+and `target-material-kind-contract.md` §4.1):
 
 | Behavior | Requirement |
 |---|---|

package/.onto/processes/shared/pipeline-execution-ledger-contract.md

@@ -81,9 +81,98 @@ interface PipelineExecutionLedgerUnitEntry {
   lastFailureMessage: string | null;
   upstreamUnitIds: string[];
   downstreamUnitIds: string[];
+  executionTelemetry?: PipelineUnitExecutionTelemetry | null;
+}
+
+interface PipelineUnitExecutionTelemetry {
+  unit_id: string;
+  llm_call_count: number;
+  duration_ms: number;
+  prompt_chars: number;
+  output_chars: number;
+  provider_tokens_in: number | null;
+  provider_tokens_out: number | null;
+  provider_route: string | null;
+  model_id: string | null;
+  effort: string | null;
+  prompt_policy_sha256: string | null;
+  source_identity_refs: string[];
+  attempt_count: number;
+  attempts: Array<{
+    attempt: number;
+    // open sets: known members + (string & {}) — see "additively-extensible" rule below
+    kind: "initial" | "parse_repair" | "semantic_repair" | "timeout_recovery" | "validation_gate" | (string & {});
+    status: "succeeded" | "failed";
+    failure_class:
+      | "malformed_json"
+      | "parse_repair_failure"
+      | "schema_validation_failure"
+      | "timeout"
+      | "provider_error"
+      | (string & {})
+      | null;
+    failure_message: string | null;
+    duration_ms: number;
+  }>;
+  batch_count: number | null;
 }
 ```
 
+Execution telemetry rules:
+
+- Telemetry is runtime-owned. It is recorded at the LLM call boundary by the
+  producing pipeline; LLMs have no authority over any telemetry value.
+- `prompt_chars`/`output_chars` are the canonical size measure for speed and
+  size comparisons: runtime computes them directly, so they are always
+  available and comparable across providers and mock realizations. Provider
+  token usage (`provider_tokens_in/out`) is a supplemental fact recorded only
+  when the provider reports it; comparisons are valid only between runs using
+  the same measure and the same provider route.
+- One attempt row is recorded per actual LLM call (`initial`, `parse_repair`,
+  `semantic_repair`, `timeout_recovery`); these increment `llm_call_count` and
+  the size counters. In addition, a `validation_gate` attempt row is recorded
+  when a deterministic validation gate rejects an authored artifact before a
+  feedback retry: it carries `status: "failed"` and
+  `failure_class: "schema_validation_failure"`, increments `attempt_count` so
+  the validation miss stays visible in the recovered unit's lineage, but does
+  not count as an LLM call (no `llm_call_count`/size contribution). `failure_class`
+  separates output-shape failures (`malformed_json`, `parse_repair_failure`),
+  validation-gate misses (`schema_validation_failure`), and transport failures
+  (`timeout`, `provider_error`).
+- `kind` and `failure_class` are **additively-extensible, forward-compatible
+  sets**: handling of LLM input/output is a cross-pipeline concern and LLM
+  response/failure characteristics are not under our control, so the shared
+  ledger evolves to represent them (new kinds/classes are added as new
+  failure-handling or recovery shapes are introduced). Such additions are
+  backward-compatible and do **not** bump `schemaVersion`; consumers MUST treat
+  the sets as open and tolerate an unknown `kind`/`failure_class` (record or
+  pass it through) rather than reject the artifact. `validation_gate` /
+  `schema_validation_failure` were added under this policy.
+- `prompt_policy_sha256` is a source-layer identity fact: the hash of the
+  unit's first initial system prompt, so before/after comparisons can
+  attribute metric deltas to prompt-policy changes. Run-level source-layer
+  identities (registry/contract/profile/validator snapshots) remain owned by
+  the run manifest's governing snapshot.
+- `source_identity_refs` is the extensible runtime-owned identity list for
+  metric attribution. Each ref is a `<kind>:<value>` string. Current kinds:
+  `prompt_policy_sha256:<hash>` and `authored_artifact:<name>` (one per
+  distinct authored-artifact variant the unit executed; initial, repair, and
+  recovery artifact names identify the payload-contract seat). Comparators
+  must treat a metric delta as attributable only when the dependent identity
+  refs are present on both sides.
+- Telemetry unit ownership is fail-loud: an authored artifact without a unit
+  mapping is a contract error at call time, not a silent telemetry omission.
+- Ledger-level `lastFailureMessage` means terminal unit failure only: it is
+  set from telemetry when the unit's final recorded attempt failed. Recovered
+  intermediate failures (for example a repaired malformed output) stay
+  visible in `attempts` and must not surface as `lastFailureMessage`.
+- `batch_count` records deterministic prompt batching (for example
+  competency-question assessment) so batching changes stay attributable.
+- Units that made no LLM call carry no telemetry field; absence is not a
+  failure signal.
+- Current population status: `reconstruct` populates telemetry from its run
+  manifest steps. `review` does not populate it yet.
+
 Rules:
 
 - `trusted` requires the producing unit to complete and all required output

package/.onto/processes/shared/target-material-kind-contract.md

@@ -3,6 +3,11 @@
 > Status: design goal contract, partially registered in core lexicon.
 > Purpose: define the cross-process goal for material-aware target handling
 > across `review`, `reconstruct`, and future `evolve`.
+> Note: "design goal / partially registered" describes the cross-process axis and
+> `runtime_implementation_status`, not contract activeness. For the `reconstruct`
+> slice specifically, `target-material-profile.yaml` and `material_profile_gate`
+> are already contract-active per
+> `reconstruct-contract-registry.yaml#validation_gate_catalog` / `#artifact_authorities`.
 
 Related shared contract:
 
@@ -59,15 +64,18 @@ Allowed values:
 | `mixed` | Bundle containing more than one material kind. Each member needs its own material classification; `mixed` itself is not an adapter target. |
 | `unknown` | Runtime cannot classify the material safely. Adapter execution must halt or ask for clarification. |
 
-The axis is separate from:
+The axis is separate from these other classifying axes. They are not peers in
+ownership: the first two are lexicon-owned; the rest are review-contract-local
+concepts cited here for orthogonality only, not owned by this shared contract or
+the lexicon.
 
-| Axis | Question answered |
-|---|---|
-| `domain` | What is the target about? |
-| `medium` | Which cross-product implementation or reference frame accumulates reusable learning? |
-| `target_input_kind` | How did the target enter runtime? |
-| `artifact_roles` | What responsibility does the artifact carry in this run? |
-| review context `source_kind` | Which context-source artifact is being admitted into prompt packets? |
+| Axis | Question answered | Defined in (owner) |
+|---|---|---|
+| `domain` | What is the target about? | core-lexicon (rank-1) |
+| `medium` | Which cross-product implementation or reference frame accumulates reusable learning? | core-lexicon (rank-1) |
+| `target_input_kind` | How did the target enter runtime? | `review-target-profile-contract.md` §5 (review-owned; reconstruct UX references it — promote to a shared/lexicon home only if reconstruct adopts it as a formal field) |
+| `artifact_roles` | What responsibility does the artifact carry in this run? | `review-target-profile-contract.md` §5 (review-owned) |
+| review context `source_kind` | Which context-source artifact is being admitted into prompt packets? | review context contracts (review-owned; reconstruct deliberately does not use it) |
 
 ## 4. Cross-Process Alignment
 
@@ -161,6 +169,9 @@ Runtime must validate:
 
 Before full runtime implementation, at least one prompt-backed reference run
 must produce the planned artifact shapes and an acceptance observation.
+("Before full runtime implementation" here scopes `runtime_implementation_status`
+and review/future-`evolve` adoption; it does not mean the `reconstruct` material
+profile/gate are unbuilt — those are contract-active per the registry.)
 
 Recommended reference targets:
 
@@ -177,35 +188,25 @@ Historical reference-run evidence is isolated outside runtime reference context.
 Current runtime authority is the artifact contract in this file plus the
 review/reconstruct process contracts that consume it.
 
-## 9. UX Output Contract
-
-Opening output should expose:
-
-- selected environment, process, model, and domain
-- requested target and detected `target_material_kind`
-- planned material reading strategy
-- unsupported or partial-support status
-- runtime responsibilities and LLM responsibilities
-
-Progress output should expose:
-
-- material detection result
-- inventory completion
-- observation counts by material kind
-- directive validation status
-- unsupported, unknown, or skipped material members
-
-Result output should separate:
-
-- material observations collected
-- semantic claims promoted by LLM directives
-- evidence gaps
-- unsupported or out-of-scope material
-- next action candidates
-
-The output contract should be rendered by the host LLM from runtime facts or by
-existing CLI/MCP status surfaces. Do not add a separate HTML implementation just
-to display this progress.
+## 9. UX Output Contract — Material-Kind Delta
+
+The full opening/progress/result run-UX skeleton is owned by each process's UX
+contract (reconstruct: `reconstruct-execution-ux-contract.md` §§2-6; review: its
+own status/result surfaces). To keep these same-rank contracts from drifting,
+this section owns only the **material-kind delta** those surfaces must
+additionally expose:
+
+- opening: detected `target_material_kind`, planned material reading strategy, and
+  unsupported/partial-support status
+- progress: material detection result, observation counts by material kind, and
+  unsupported/unknown/skipped material members
+- result: material observations collected vs semantic claims promoted by LLM
+  directives, and unsupported or out-of-scope material
+
+The host LLM renders these from runtime facts or existing CLI/MCP status surfaces;
+do not add a separate HTML implementation. The generic environment/process/model/
+domain exposure and the observations-vs-claims-vs-gaps separation are defined once
+in the process UX contracts and are not restated here.
 
 ## 10. Goal Completion Conditions
 

package/dist/cli.js

@@ -39,6 +39,7 @@ function printHelp() {
         "Active interface:",
         "  mcp            Start the MCP stdio tool server",
         "  register       Register the onto MCP server into supported hosts",
+        "  configure-provider  Write LLM provider settings into the settings.json chain",
         "",
         "Available MCP tools:",
         "  onto_review",
@@ -62,7 +63,7 @@ function printHelp() {
 function unsupportedCommandMessage(subcommand) {
     return [
         `[onto] Unsupported public CLI subcommand: ${subcommand}`,
-        "Active public commands: onto mcp, onto register",
+        "Active public commands: onto mcp, onto register, onto configure-provider",
     ].join("\n");
 }
 async function main() {
@@ -79,6 +80,10 @@ async function main() {
             const { runRegister } = await import("./core-runtime/onboard/register.js");
             return runRegister(argv.slice(1));
         }
+        case "configure-provider": {
+            const { runConfigureProvider } = await import("./core-runtime/onboard/configure-provider.js");
+            return runConfigureProvider(argv.slice(1));
+        }
         case "--version":
         case "-v": {
             const version = await readOntoVersion();