onto-mcp 0.3.0 → 0.3.2

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

@@ -0,0 +1,177 @@
+# Reconstruct Execution UX Contract
+
+> Status: design contract.
+> Purpose: define the user-visible reconstruct run experience without adding a
+> separate UI implementation.
+
+## 1. Position
+
+`reconstruct` can take a long time because the host LLM must read source
+observations, run reconstruct lens judgments, choose the next unjudged source
+frontier, propose Seed meaning, assess competency questions, and explain
+unresolved gaps. The user-facing experience must therefore expose new
+information as it is discovered, not only meta status such as "still running".
+
+The runtime owns structured facts, stage ids, artifact refs, liveness hints, and
+deterministic counts. The host LLM owns the short explanation shown to the user.
+
+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.
+
+## 2. Opening Brief
+
+At run start, the host should show a compact opening brief before expensive
+work begins.
+
+The brief must include:
+
+- environment: project root or declared source boundary, session root, and
+  write policy
+- method: MCP/runtime path, source profile, semantic author realization, and
+  confirmation provider realization
+- execution profile: observer/gate slice, full integral exploration, or a
+  test/fixture-only profile if a non-product harness is running, with the
+  completion claim allowed for that profile
+- model/provider: provider family or realization label without secrets
+- domain: selected domain, no-domain mode, or pending domain-context selection
+- material: `target_material_kind`, target input kind, and unsupported-material
+  status if known
+- exploration loop: initial source frontier, round budget if any, and frontier
+  validation policy
+- reconstruction direction: what the reconstruct run will try to explain, and
+  what it will treat as out of scope
+- ownership boundary: runtime observes and validates; reconstruct lenses judge
+  meaning and source gaps; the user or host confirmation controls Seed
+  acceptance
+- skipped or deferred stages that already narrow downstream authority, such as
+  live lens judgment, source-frontier exploration, domain-context selection,
+  user confirmation, or competency-question assessment
+
+The opening brief should be declarative. It should not ask the user to approve
+internal implementation details unless the target boundary, domain, or write
+policy is ambiguous.
+
+## 3. Progress Presentation
+
+Progress is stepwise and round-aware. Each update should include the current
+`ReconstructStageId`, exploration round id when applicable, a short label, a
+liveness state, and one or two newly learned facts.
+
+Recommended update shape:
+
+```text
+[round 2 | stage source_frontier_validation] source_frontier
+Status: running
+Learned: coverage requested billing service tests and rejected one already-seen helper.
+Next: observe 3 accepted source refs inside the declared project boundary.
+```
+
+Progress updates should prefer facts such as:
+
+- material kind and profile confidence
+- scanned roots and skipped boundaries
+- initial source frontier artifact ref and first-observation source refs
+- source inventory counts by material-specific unit
+- exploration round count and new observation count by round
+- selected observation count and evidence-candidate rationale
+- per-lens judgment status and newly named semantic gaps
+- source frontier refs requested, accepted, rejected, already observed,
+  unsupported, or out of bounds
+- domain context refs and snapshot id
+- Seed claim count by entity, relation, action, property, and rule
+- claim realization stance counts
+- confirmation state counts
+- competency question count and assessment status counts
+- failure classification counts
+- revision proposal action counts
+- unresolved, deferred, and out-of-scope counts
+- current halt reason and reusable artifact refs when halted
+- skipped/deferred stage reason and downstream authority impact
+
+Progress updates should avoid pretending that intermediate semantic claims are
+final. Before Seed confirmation, claims are candidates. Before competency
+question assessment, quality statements are preliminary.
+
+## 4. Decision Points
+
+User-facing prompts are needed only when a decision changes the product result
+or the allowed boundary.
+
+Decision points:
+
+- target boundary is ambiguous or would require reading outside the bound root
+- material kind is unsupported or mixed in a way that changes adapter behavior
+- source frontier expansion would exceed the declared boundary, adapter support,
+  or round/cost budget
+- domain context selection changes the interpretation standard
+- Seed claim confirmation requires accepted, rejected, partial, or deferred
+  state
+- unresolved material questions require a final direction: continue, defer, or
+  accept with disclosed limits
+
+The host should phrase choices by outcome, not internal jargon.
+
+## 5. Final Output
+
+`final-output.md` must be decision-ready and artifact-tethered. It should
+separate:
+
+- confirmed Seed content
+- claim realization summary
+- competency question assessment summary
+- material failures and unsafe-to-trust gaps
+- revision proposals and action candidates
+- unresolved, deferred, unsupported, or out-of-scope items
+- artifact provenance: the owning ids and artifact refs behind the statements
+- execution profile and completion scope: what actually ran, what was skipped,
+  and which downstream authority claims are therefore narrowed
+
+The final output is not the authority for truth. It is a user-facing projection
+of `reconstruct-record.yaml`, `reconstruct-run-manifest.yaml`, and the
+stage-owned artifacts.
+
+Full integral exploration wording is allowed only when the run manifest records
+the full profile and the required exploration, domain-context, Seed,
+confirmation, competency-question, assessment, failure, revision, metrics, stop,
+and final-output stages are trusted or explicitly skipped with trusted reasons.
+
+## 6. Halted Or Partial Runs
+
+If a run halts, the output should still be useful:
+
+- show the last completed stage id
+- show which artifact refs are reusable
+- show which stage failed and why
+- show the strongest safe statement supported by completed artifacts
+- show the latest accepted/rejected source frontier refs if the halt happened
+  inside exploration
+- avoid summarizing missing stages as if they ran
+- show the execution profile and the exact completion claim still supported by
+  trusted artifacts
+
+A halted run may provide candidate Seed content only if the corresponding
+artifact and validation refs exist. It may not imply Seed confirmation, CQ
+assessment, failure classification, revision proposal, stop decision, or final
+ontology direction unless those artifacts exist.
+
+## 7. Runtime Payload Expectations
+
+Future status/result payloads should expose enough facts for the host LLM to
+render this contract without scraping prose:
+
+- execution profile and allowed completion claim
+- current stage id and total planned stage count
+- current exploration round id, round state, and round budget if any
+- stage state: pending, running, completed, skipped, or halted
+- skipped/deferred stage reason and `authority_impact`
+- stage artifact refs and owner
+- liveness state and recommended polling interval
+- deterministic count summaries from the latest completed artifacts
+- latest source frontier summary and reusable trusted observation refs
+- initial source frontier artifact ref
+- unresolved/deferred/out-of-scope summaries
+- opening, progress, halt, and final presentation prompts or facts
+
+The payload may be compact. It should expose bounded facts and artifact refs,
+not duplicate semantic authority.

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

@@ -1,6 +1,6 @@
 # Reconstruct Source Profile Contract
 
-> Status: design contract, not wired runtime.
+> Status: design contract, partially wired runtime.
 > Purpose: define target-material observation contracts for `reconstruct`.
 
 ## 1. Canonical Seat
@@ -15,6 +15,11 @@ The historical `explorers/` folder is archived and must not be revived as an
 active runtime path. `SourceProfile` is the current name because the file guides
 runtime observation. It is not an autonomous semantic explorer.
 
+In the integral exploration design, source profiles still belong to the runtime
+observation side. Reconstruct lenses may ask for additional source refs through
+a validated source frontier, but the profile itself does not decide which source
+is semantically important.
+
 Source profiles are keyed by `target_material_kind`, the shared runtime axis
 defined in `.onto/authority/core-lexicon.yaml`. They must not use `source_kind`
 to mean code, spreadsheet, document, or database because review already uses
@@ -32,6 +37,8 @@ Current source profiles:
 | `spreadsheet` | `.onto/processes/reconstruct/source-profiles/spreadsheet.md` |
 | `database` | `.onto/processes/reconstruct/source-profiles/database.md` |
 | `document` | `.onto/processes/reconstruct/source-profiles/document.md` |
+| `mixed` | no standalone parser profile; requires per-member profiles or explicit unsupported/halt behavior |
+| `unknown` | no profile; runtime must halt or ask for clarification |
 
 ## 2. Profile Responsibility
 
@@ -43,11 +50,13 @@ A source profile may define:
 - detail location notation
 - context questions
 - scan targets
+- safe frontier-ref shapes for this material kind
 - correct and incorrect observation examples
 - current support status and explicit unsupported cases
 
 A source profile must not define rules that convert source structure into
-ontology concepts.
+ontology concepts or rules that choose the next source based on ontology
+meaning.
 
 Examples:
 
@@ -65,11 +74,17 @@ return observations, but they do not interpret ontology meaning. The source
 profile may guide observation scope, but the adapter schema is the runtime
 contract that fixes returned fields and observation ids.
 
+When a source adapter is invoked after the first round, it consumes only
+runtime-validated source frontier refs. It must not accept lens prose or
+semantic labels as source locations.
+
 The future adapter contract must fail explicitly when:
 
 - the target material kind cannot be resolved
 - the source format is unsupported
 - the target is outside the declared filesystem or connection boundary
+- a requested source frontier ref is not a concrete source location for this
+  material kind
 - an observation ref cited by a directive does not exist
 - required parser/tool support is unavailable
 
@@ -86,13 +101,16 @@ Every profile must make the material-specific reading strategy visible:
 | `spreadsheet` | Inspect workbook/sheet/range/formula/formatting structure without declaring accounting or business meaning. |
 | `document` | Inspect sections, headings, quotes, tables, references, and definitions without choosing canonical business rules. |
 | `database` | Inspect schemas, tables, columns, constraints, indexes, and queries without assigning business relation meaning. |
-| `mixed` | Inventory each member with its own material kind and preserve cross-material refs without collapsing them into one parser. |
+| `mixed` | Inventory each member with its own material kind and preserve cross-material refs without collapsing them into one parser. If a composite profile is not implemented, halt or ask before adapter dispatch. |
 | `unknown` | Halt or ask for clarification; do not guess an adapter. |
 
 Domain interpretation happens after observation. For example, an accounting
 spreadsheet is `target_material_kind=spreadsheet` and may use `domain=accounting`;
 the spreadsheet adapter reports cells and formulas, while the LLM interprets
-accounting meaning from evidence and selected domain documents.
+accounting meaning from evidence and selected domain documents. If that
+interpretation shows that another sheet, range, document section, table, or code
+file is needed, the host LLM writes a source frontier directive and runtime
+validates it before any additional observation occurs.
 
 ## 5. Extension Rule
 
@@ -100,8 +118,23 @@ Adding a new target material kind requires:
 
 1. A new source profile under `.onto/processes/reconstruct/source-profiles/`.
 2. Runtime adapter support or an explicit unsupported status.
-3. Tests for target material detection, observation shape, unsupported inputs,
-   and directive evidence-ref validation.
+3. Tests for target material detection, observation shape, source frontier
+   validation, unsupported inputs, and directive evidence-ref validation.
 4. MCP schema updates only after the runtime contract is implemented.
 
 The source profile alone does not make a target material kind supported.
+
+## 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:
+
+| Behavior | Requirement |
+|---|---|
+| supported composite | Runtime writes per-member material classification, dispatches only supported member profiles, and preserves cross-material refs in inventory and observations. |
+| partial composite | Runtime observes supported members, records unsupported members separately, and exposes the downstream authority limit. |
+| unsupported | Runtime halts or asks for clarification with a stable unsupported reason before adapter dispatch. |
+
+No source profile may treat `mixed` as a shortcut for reading a bundle with one
+adapter. Cross-material semantic meaning remains LLM-owned and must be grounded
+in per-member observations plus validated cross-material refs.

package/.onto/processes/reconstruct/top-level-concept-discovery-contract.md

@@ -0,0 +1,387 @@
+# Reconstruct Top-Level Concept Discovery Contract
+
+> Status: design contract.
+> Purpose: define how `reconstruct` discovers purpose-relative top-level
+> concepts for an ontology Seed without turning the Seed into a broad claim
+> ledger or a full ontology draft.
+
+## 1. Position
+
+`reconstruct` Seed generation is a top-level concept discovery process.
+
+The Seed is not the full ontology. It is not a complete list of entities,
+relations, actions, properties, rules, implementation details, or all possible
+evidence-backed claims. Its purpose is to identify the smallest stable set of
+top-level concepts that explains the declared purpose of the target material,
+with explicit boundaries, evidence, open questions, and deferred lower-level
+details.
+
+Top-level concepts are purpose-relative. They are not the highest possible
+abstractions in a universal hierarchy. A concept is top-level for a reconstruct
+run when it is the most useful stable axis for explaining the declared purpose
+from the observed source evidence.
+
+Example:
+
+```text
+RawIngestEvent
+-> Usage Event
+-> Usage Activity
+-> User Behavior
+-> Organizational Knowledge Flow
+```
+
+For an AI usage dashboard Seed, `Usage Event` may be a top-level concept while
+`Organizational Knowledge Flow` is too abstract and `RawIngestEvent` is usually
+a lower-level implementation detail.
+
+## 2. Ownership Boundary
+
+Runtime owns material-aware observation, source inventories, artifact refs,
+validation gates, deterministic metrics, and source frontier boundary checks.
+
+The host LLM owns semantic grouping, abstraction-level judgment, top-level
+concept naming, boundary explanation, relation interpretation, convergence
+interpretation, and final user-facing explanation.
+
+Runtime must not decide that a source symbol, spreadsheet range, document
+section, database table, UI component, or service method is a top-level concept.
+Runtime may validate that LLM-authored top-level concept artifacts cite known
+evidence refs and preserve declared artifact shape.
+
+## 3. Design-Local Terms
+
+These names are design-contract terms until promoted through the concept
+registration gate in `reconstruct-boundary-contract.md`.
+
+| Term | Seat | Meaning |
+|---|---|---|
+| `TopLevelConcept` | reconstruct-local semantic artifact candidate | Purpose-relative concept that explains multiple lower-level observations and remains stable across likely implementation changes. |
+| `TopLevelConceptSet` | reconstruct-local semantic artifact candidate | Small selected set of top-level concepts for the declared purpose. |
+| `LowerLevelDetail` | design shorthand | Source-specific field, method, component, rule, property, table, sheet, or claim that should support a top-level concept rather than become the Seed center. |
+| `TopLevelnessPressure` | design shorthand | Unresolved reason that may change the selected concept set, concept boundary, or core relation. |
+| `ConceptConvergence` | design shorthand | State where further source exploration is expected to refine evidence or details rather than materially change the top-level concept set, boundaries, or core relations. |
+
+Do not introduce these names as TypeScript types, MCP fields, public artifact
+fields, or enum values before the concept registration gate is explicitly
+closed.
+
+## 4. Discovery Strategy
+
+Top-level concept discovery uses bottom-up observation, top-down purpose
+constraint, and graph compression.
+
+The process is not "keep climbing the hierarchy." It alternates between lifting
+source details into candidate concepts and grounding those candidates back into
+the declared purpose and observed evidence.
+
+```text
+material-aware source observations
+-> local semantic labels and gaps
+-> candidate concept clusters
+-> abstraction-level tests
+-> top-level concept set
+-> source frontier aligned to unresolved top-levelness pressure
+-> convergence assessment
+```
+
+### 4.1 Collect Local Candidates
+
+The first semantic pass may name many local candidates from files, symbols,
+tables, fields, formulas, headings, UI components, services, actions, states,
+rules, and document claims. This pass should avoid deciding top-level status too
+early.
+
+Local candidates are evidence-bearing raw material for clustering. They are not
+Seed output by default.
+
+### 4.2 Cluster By Purpose Role
+
+Local candidates should be clustered by the role they play in explaining the
+declared purpose:
+
+- shared lifecycle
+- shared user-facing meaning
+- shared source flow
+- shared ownership or authority
+- shared change fate
+- repeated co-occurrence across material slices
+- ability to explain multiple lower-level observations
+
+Example for an AI usage dashboard:
+
+| Local candidates | Candidate top-level concept |
+|---|---|
+| session row, session metrics, session context, session classification | `Usage Session` |
+| raw payload, ingest event, fingerprint, deduplication status | `Usage Event` |
+| billing aggregate, cost KPI, token cost, provider cost | `Usage Cost` |
+| page, KPI cards, session table, analytics summary | `Dashboard View` |
+
+### 4.3 Test Abstraction Level
+
+Each candidate must pass both upward and downward tests.
+
+Upward test:
+
+- Does this candidate explain multiple lower-level observations?
+- Does it survive likely implementation changes?
+- Is it necessary to explain the declared purpose?
+- Can a user understand it without reading implementation names?
+
+Downward test:
+
+- Is it still grounded in concrete evidence?
+- Does it avoid becoming a generic business abstraction?
+- Does it preserve enough boundary detail to guide later ontology work?
+- Does it avoid hiding materially different concepts that must be split?
+
+The target is the stable middle level that explains the purpose, not the most
+abstract reachable parent.
+
+### 4.4 Select A Small Concept Set
+
+The Seed should prefer a compact top-level concept set. The normal target range
+is small enough for a user to inspect in one pass, usually 3-7 concepts for a
+bounded product slice.
+
+The concept set may be larger when the declared purpose or target bundle is
+explicitly broad, but growth must be justified by purpose coverage, not by
+implementation surface area.
+
+### 4.5 Demote Lower-Level Detail
+
+Implementation details, fields, service methods, UI widgets, spreadsheet cells,
+schema columns, narrow rules, and action-level claims should be demoted unless
+they independently satisfy the top-level tests.
+
+Demotion does not discard evidence. The detail should be attached to one of:
+
+- `included_lower_concepts`
+- `supporting_evidence`
+- `deferred_detail_candidates`
+- `open_questions`
+- `boundary_notes`
+
+## 5. Top-Levelness Criteria
+
+A top-level concept candidate is strong when it satisfies most of the criteria
+below.
+
+| Criterion | Question |
+|---|---|
+| Purpose criticality | Would the declared purpose become hard to explain without this concept? |
+| Explanatory compression | Does it explain multiple lower-level observations without losing important distinctions? |
+| Boundary clarity | Can the run state what belongs under this concept and what is excluded or deferred? |
+| Relation centrality | Does it participate in core relations with other selected concepts? |
+| Material grounding | Is it supported by concrete source observations from the current material boundary? |
+| User-facing intelligibility | Can the concept be named in service language, not only implementation language? |
+| Evolution stability | Would the concept likely survive refactors, UI rewrites, schema reshaping, or source-format changes? |
+| Split pressure | Is there no unresolved material reason to split it now? |
+| Merge pressure | Is there no unresolved material reason to merge it with another selected concept now? |
+
+No single criterion is sufficient. Frequent source mentions or central code
+location do not by themselves make a concept top-level.
+
+## 6. Source Frontier Alignment
+
+Source frontier selection must align to top-level concept convergence.
+
+The frontier should not ask "what else can be read?" It should ask "what source
+could materially change the selected top-level concept set, concept boundaries,
+core relations, or convergence confidence?"
+
+Each LLM-authored frontier ref should carry the decision pressure it is meant
+to resolve.
+
+Recommended semantic payload:
+
+```yaml
+frontier_refs:
+  - source_ref: src/services/usage-mart.service.ts
+    frontier_question: Is UsageMart a top-level concept or a lower-level read model under Usage Cost or Dashboard View?
+    target_concepts:
+      - Usage Cost
+      - Dashboard View
+      - Usage Mart
+    pressure_type: split_or_demote
+    expected_decision_impact: May demote UsageMart from top-level concept to supporting detail.
+    priority: high
+```
+
+The exact public artifact field names remain subject to the registration gate.
+Until then, runtime may preserve this information inside existing rationale
+fields or design-local prompt payloads.
+
+Valid frontier pressure categories:
+
+| Pressure | Use when |
+|---|---|
+| `missing_axis` | The declared purpose may require a top-level concept not yet represented. |
+| `split_or_merge` | Two candidates may be the same concept, or one candidate may hide two materially different concepts. |
+| `boundary` | The concept's included and excluded lower-level details are unclear. |
+| `core_relation` | The relation between selected concepts may be wrong or incomplete. |
+| `abstraction_level` | A candidate may be too implementation-specific or too generic. |
+| `evidence_saturation` | The run needs to know whether additional source will introduce new top-level concepts or only reinforce existing ones. |
+
+Frontier requests that only gather lower-level implementation detail are valid
+only when that detail can resolve one of these pressures.
+
+## 7. Convergence Conditions
+
+Top-level concept discovery converges when further source exploration is
+expected to refine evidence, properties, rules, or lower-level details, but is
+not expected to materially change the selected top-level concept set, each
+concept's boundary, or the core relations between concepts for the declared
+purpose.
+
+Convergence is not the absence of all issues. It is a bounded claim about the
+stability of the top-level concept set.
+
+The run may report one of three convergence states:
+
+| State | Meaning | Typical next action |
+|---|---|---|
+| `not_converged` | Top-level concept candidates, boundaries, or relations are still changing materially. | Continue source frontier exploration. |
+| `provisionally_converged` | The main concept set is stable, but some split, merge, boundary, or deferred-detail questions remain. | Present Seed with disclosed limits and revision proposals. |
+| `converged_for_seed` | Purpose coverage, concept boundaries, and core relations are stable enough for Seed handoff. | Present Seed as the current top-level concept discovery result. |
+
+Signals for convergence:
+
+- selected concept set is stable across the latest exploration round
+- new observations map into existing concepts rather than creating new top-level
+  concepts
+- remaining issues concern evidence depth, properties, rules, or lower-level
+  details
+- no lens raises a material objection that a selected concept is too broad, too
+  narrow, too generic, too implementation-specific, missing, or duplicated
+- next frontier value is expected to improve confidence rather than change the
+  concept set
+
+Signals against convergence:
+
+- a new source slice introduces a previously missing purpose axis
+- selected concepts repeatedly require split or merge
+- relation direction between selected concepts changes
+- a selected concept cannot state included and excluded detail
+- a concept is only a code artifact, UI widget, schema artifact, spreadsheet
+  range, or document section with no purpose-level role
+- the concept set explains source structure but not the declared purpose
+
+## 8. Seed Output Shape
+
+The Seed should center top-level concepts. Current artifacts may continue to use
+existing Seed claim fields while the contract migrates, but the semantic shape
+should project to:
+
+```yaml
+purpose:
+  claim_id:
+  name:
+  statement:
+  evidence_refs:
+top_level_concepts:
+  - concept_id:
+    name:
+    definition:
+    why_top_level:
+    evidence_refs:
+    included_lower_concepts:
+    excluded_or_deferred_details:
+    core_relations:
+    open_questions:
+    confidence:
+top_level_relations:
+  - relation_id:
+    source_concept_id:
+    target_concept_id:
+    relation:
+    statement:
+    evidence_refs:
+deferred_detail_candidates:
+  - name:
+    belongs_to_concept_id:
+    reason_deferred:
+    evidence_refs:
+convergence:
+  state:
+  rationale:
+  remaining_pressures:
+```
+
+If existing `entities`, `relations`, `actions`, `properties`, and `rules`
+fields are used before schema migration, they must be interpreted narrowly:
+
+- `entities` should contain only top-level concept candidates or explicitly
+  marked provisional top-level entities.
+- `relations` should contain only relations between top-level concepts.
+- `actions`, `properties`, and `rules` should be sparse and limited to
+  purpose-level facts that affect top-level concept boundaries or relations.
+- lower-level actions, properties, rules, fields, methods, UI elements, and
+  schema details should move to deferred detail or supporting notes.
+
+## 9. Lens Responsibilities
+
+Reconstruct lenses should evaluate top-level concept discovery rather than
+merely collecting claim improvements.
+
+| Lens | Discovery question |
+|---|---|
+| semantics | Are the concept names and definitions meaningfully distinct and grounded? |
+| structure | Is the concept set neither over-split nor over-merged? |
+| dependency | Do selected concepts have stable dependency and flow relations? |
+| pragmatics | Can target users understand and act on this concept set? |
+| evolution | Will the concepts survive likely implementation and material changes? |
+| coverage | Does the set cover the declared purpose without missing a major axis? |
+| logic | Are relations and boundaries coherent and non-contradictory? |
+| conciseness | Is the Seed compact enough to serve as a Seed rather than a full ontology? |
+| axiology | Does the concept set preserve what matters for trust, value, and declared purpose? |
+
+Lens disagreement should be represented as split, merge, boundary, abstraction,
+or missing-axis pressure when it can affect top-level convergence.
+
+## 10. Validation Expectations
+
+Runtime validation should remain deterministic. It can validate:
+
+- artifact shape
+- required fields
+- known evidence refs
+- duplicate ids
+- relation endpoints referencing known top-level concepts
+- every top-level concept having at least one evidence ref
+- every top-level concept having a boundary statement
+- convergence state being one of the allowed values once promoted
+
+Runtime should not validate semantic truth such as whether `Usage Session` is
+really the right top-level concept. That remains LLM-authored and lens-reviewed.
+
+## 11. Non-Goals
+
+This contract does not require:
+
+- a full ontology graph
+- exhaustive entity extraction
+- automatic semantic repair by runtime
+- a universal hierarchy of concepts
+- reading every source file
+- turning every source detail into a Seed claim
+- declaring lower-level implementation details final
+
+## 12. Implementation Path
+
+Recommended implementation order:
+
+1. Update the Seed author prompt to make top-level concept discovery the primary
+   objective.
+2. Add compact prompt payloads that pass candidate labels, gaps, evidence ids,
+   and unresolved top-levelness pressure rather than full artifacts.
+3. Add a design-local top-level concept projection in final output before
+   changing public schema.
+4. Add Seed validation checks for required `name`, boundary, evidence, compact
+   concept set, and relation endpoints.
+5. Add frontier rationale fields or prompt requirements that align every
+   source frontier request to top-level concept pressure.
+6. Add convergence projection to metrics and final output.
+7. Promote stable names through `.onto/authority/core-lexicon.yaml` only after
+   the artifact shape has stabilized.
+

package/.onto/processes/review/binding-contract.md

@@ -226,6 +226,14 @@ binding_notes:
 recommendation, explicit token, 주체자 확인 결과를
 최종 값으로 materialize한 결과여야 한다.
 
+단, interpretation/config 단계에서 explicit domain이 없고 configured domain도
+없으면 runtime은 review target의 path/content/intent와 available domain 문서의
+bounded signal을 비교해 `domain_final_selection`을 자동 materialize할 수 있다.
+이 경우 `selection_mode`는 target 기반 자동 선택임을 드러내야 하며,
+왜 해당 domain을 골랐는지는 `binding_notes`에 사용자에게 설명 가능한 문장으로
+남긴다. 충분한 signal이 없어서 `none`으로 가는 경우도 같은 방식으로 이유를
+남긴다.
+
 ---
 
 ## 7. Prompt / MCP / Runtime Effect