yarramate 0.14.0 → 0.16.0

package/README.md

@@ -5,168 +5,221 @@
 [![CodeQL](https://github.com/yarrasys/yarramate/actions/workflows/codeql.yml/badge.svg)](https://github.com/yarrasys/yarramate/actions/workflows/codeql.yml)
 [![license: MIT](https://img.shields.io/github/license/yarrasys/yarramate)](LICENSE)
 
-Product site: **[yarramate.dev](https://yarramate.dev)**
+**[yarramate.dev](https://yarramate.dev)** ·
+[Case study](docs/CASE-STUDY-CROSS-HARNESS.md) ·
+[Documentation](docs/README.md)
 
-YarraMate keeps your coding agents' architecture context correct. Declare
-the design once, as a checked model in git; agents receive prose rendered
-from it — bounded briefs and open design questions — and the CLI
+Your coding agents re-derive your system's design every session — and each
+one derives it a little differently. The design document that could stop
+them says whatever it said the day someone last edited it.
+
+YarraMate keeps the design as a small, checked model in git instead. Agents
+and people read prose rendered from it — bounded briefs and open design
+questions — write decisions back through validated batches, and the CLI
 mechanically proves the model still matches the code as changes land.
 
-Prose is the interface; structure is the guarantee: every sentence an agent
-reads stands on a graph whose names resolve, whose drift is detected, and
-whose gaps are found deterministically.
+There is no LLM inside and no service behind it: the engine is a
+deterministic CLI, nothing leaves your repository, and git remains the only
+governance — a proposed change becomes architecture when a human merges it.
 
 > YarraMate is pre-release software. Interfaces may evolve before the first
 > stable release.
 
-## Proven across harnesses
+## Two minutes to a model
 
-The design bet is that the model — not the session — is the state, so any
-agent in any harness can resume the work cold. We tested that adversarially
-on a real product: a Claude Code session worked the design interview all
-day, then an OpenAI Codex session — no shared context, the tool never
-named — resumed it from a ten-line pointer file and the published CLI. It
-answered 63 open design questions, filed two genuine defect reports, and in
-a later session reported that the model "was not merely documentation" — it
-caught an approval-path regression before the release shipped.
+```sh
+npm install -g yarramate
 
-The full story, with every commit, PR, and release attached:
-[The model is the handover](docs/CASE-STUDY-CROSS-HARNESS.md).
+yarramate init .                                 # scaffold .yarramate/, write the agent pointer
+yarramate design .yarramate/workspace.yaml       # the interview: the top open design question
+yarramate apply answers.yaml .yarramate/workspace.yaml   # answers land as one atomic batch
+yarramate check .yarramate/workspace.yaml        # names resolve and rules hold — or it says where not
+```
 
-## Why YarraMate?
+The whole surface is seven verbs, one per lifecycle stage:
 
-Architecture documents often drift away from implementation or become tied to
-one notation and tool. YarraMate keeps concise, native YAML documents
-canonical and compiles them into an explicit semantic graph.
+```text
+init → design → apply → ask → check → reconcile → export
+create  fill    write   read  gate    drift       derive
+```
 
-The same model supports two workflows:
+`design` recomputes the next open question from the model itself — there is
+no session state anywhere. That is the design bet: the model, not the
+session, is the state, so any agent in any harness resumes the interview
+cold, and a crashed session or a vendor switch costs nothing.
 
-- discover an existing project's architecture from repository evidence;
-- design a solution before implementation and later reconcile intent with
-  evidence.
+## Every fact is a claim
 
-Git provides authorship, review, history, and acceptance. YarraMate does not
-introduce a parallel governance workflow.
+What you author — plain YAML in git:
 
-## Product boundaries
+```yaml
+concepts:
+  - id: order-gateway
+    kind: applicationComponent
+    name: Order Gateway
+    status: current
+```
 
-YarraMate Core:
+What the engine checks — a claim in the compiled graph, with provenance:
 
-- owns native, versioned architecture documents;
-- compiles a claim-centred, tool-neutral semantic graph;
-- checks deterministic correctness rather than architectural taste;
-- supports explicit workspaces, profiles, projections, evidence, and
-  architecture states;
-- exposes a stable CLI for people, CI, skills, and agent harnesses.
+```json
+{
+  "subject": "orders#order-gateway",
+  "predicate": "yarramate/concept/kind",
+  "value": "yarramate/core@0.1#applicationComponent",
+  "origin": "declared",
+  "source": { "document": "orders", "line": 3, "column": 5 }
+}
+```
 
-Optional adapters provide:
+What an agent reads — deterministic prose rendered from the graph:
 
-- LikeC4 visualization from semantic projections;
-- Graphify observations as evidence overlays;
-- separately governed compatibility profiles for external languages.
+> "Order Gateway is an application component; it already exists in this
+> system."
 
-Core does not depend on LikeC4, Graphify, or ArchiMate.
+Every sentence stands on claims, and every claim cites the file and line it
+came from. The same YAML compiles to a byte-identical graph and the same
+sentence, every time. There is no other structure to learn: concepts,
+relationships, statuses, owners, and evidence are all claims.
 
-YarraMate is not affiliated with or certified by The Open Group. ArchiMate® is
-a registered trademark of The Open Group. LikeC4 and Graphify are independent
-projects; their mention does not imply affiliation or endorsement.
+## What structure buys
 
-## Repository layout
+Three things prose alone can't do — and deliberately the whole list:
 
-```text
-src/                 compiler, CLI, graph, and adapter sources
-schema/              normative JSON Schemas
-test/                tests and acceptance fixtures
-skills/              portable architecture workflow for agent harnesses
-.claude-plugin/      plugin marketplace manifest offering that skill
-docs/                contracts, guides, and decisions
-.yarramate/          canonical dogfooded architecture
-.yarramate-out/      reproducible generated output (ignored)
-```
+- **Identity** — a stable name every agent agrees on. References resolve or
+  the model doesn't compile; two sessions can't invent two names for the
+  same component.
+- **Verifiability** — internal consistency and drift against the code,
+  checked mechanically. A claim of "current" without supporting evidence is
+  flagged the moment it becomes checkable, and `reconcile` reports both
+  sides of every disagreement without auto-fixing either.
+- **Sliceability** — each implementer receives exactly its neighbourhood: a
+  bounded, deterministic brief rendered from the model, so parallel agents
+  share one map.
 
-The [documentation index](docs/README.md) links the public guides and
-maintainer material. Start semantic work with the
-[product contract](docs/PRODUCT-CONTRACT.md) and
-[glossary](docs/GLOSSARY.md).
+Anything a good document does as well, we leave to your documents. The model
+holds only what nothing can derive from code: what's planned, what was
+deliberately retired, who owns what, and why.
 
-## Development
+## Proven across harnesses
+
+We tested the handover bet adversarially on a real product: a Claude Code
+session worked the design interview all day, then an OpenAI Codex session —
+no shared context, the tool never named in the prompt — resumed it from a
+ten-line pointer file and the published CLI. It answered 63 open design
+questions, filed two genuine defect reports, and in a later session reported
+that the model "was not merely documentation" — it caught an approval-path
+regression before the release shipped.
+
+The full story, with every commit, PR, and release attached:
+[The model is the handover](docs/CASE-STUDY-CROSS-HARNESS.md).
 
-Requirements:
+## Research, honestly
 
-- Node.js 22 or newer
-- Corepack
+We benchmark our own claims and publish the misses alongside the wins:
 
-```sh
-corepack enable
-pnpm install --frozen-lockfile
-pnpm run verify
-```
+- **Held** — cross-harness handover; elicitation (tool-equipped agents
+  across three model tiers reached a green check first try, 5/5, and
+  converged on a design question zero freehand frontier runs ever asked);
+  lie resistance (five builds from deliberately corrupted models — zero
+  lies reached code).
+- **Not held** — under a strong external spec, a checked model did not
+  measurably beat a good design document on build convergence. We ran that
+  experiment and published it.
 
-The full CI command runs typechecking, tests, native self-validation, LikeC4
-generation, and LikeC4 validation.
+Results with full transcripts, diffs, and the adjudication trail:
+[docs/research/context-benchmark](docs/research/context-benchmark) and
+[yarramate-bench-results](https://github.com/yarrasys/yarramate-bench-results).
+
+And honestly: maintaining a model is rent. Two things make it payable —
+agents do most of the authoring through the interview loop, and the engine
+tells you exactly what's missing instead of leaving completeness to
+discipline. It pays when more than one agent, session, or human has to
+share the same map.
+
+## For AI agents
 
-Useful focused commands:
+If you are an agent working in a repository with a `.yarramate/` workspace,
+orientation is one call and the loop is three:
 
 ```sh
-pnpm build
-pnpm test
-pnpm typecheck
-pnpm self:check
-pnpm self:evidence
-pnpm self:reconcile
-pnpm self:check:likec4
-pnpm self:export:likec4
-pnpm docs:dev
+yarramate ask .yarramate/workspace.yaml      # verdict, drift summary, backlog — one round-trip
+yarramate design .yarramate/workspace.yaml   # the top open design question + its model slice
+# answer with an operations batch, then:
+yarramate apply operations.yaml .yarramate/workspace.yaml
 ```
 
-## CLI
+Re-run `design` for the next question. Stop with an uncommitted, reviewable
+diff — merging is the human acceptance step, not yours.
+
+- Every command takes `--json` and returns a versioned, schema-backed
+  envelope; writes are atomic batches that compile as a whole workspace or
+  are rejected outright, so you cannot half-corrupt a document.
+- `ask` accepts free text (`yarramate ask <ws> "billing"`), `--subjects`
+  for the full roster, `--where` for evidence-backed pointing, and
+  `--changed <git-range>` for review slices.
+- `export rtm <ws> --out <dir>` derives the requirements traceability
+  matrix: every requirement traced to its motivation, realizers, evidence
+  verdicts, and attestations, with a `path:line` citation per cell.
+- `init` writes the discovery pointer into both `AGENTS.md` and
+  `CLAUDE.md`, so this section finds you rather than the reverse.
+- `yarramate-mcp` exposes four read-only tools (ask/design/check/reconcile)
+  over MCP stdio.
+- In Claude Code, this repository is its own plugin marketplace:
+
+  ```sh
+  /plugin marketplace add yarrasys/yarramate
+  /plugin install yarramate-architecture@yarramate
+  ```
+
+The full agent contract is [docs/AGENT-INTERFACE.md](docs/AGENT-INTERFACE.md).
 
-Install the published executable or invoke it directly with `npx`:
+## Product boundaries
 
-```sh
-npm install --global yarramate
-yarramate --help
+YarraMate Core owns native, versioned architecture documents; compiles a
+claim-centred, tool-neutral semantic graph; checks deterministic correctness
+rather than architectural taste; supports explicit workspaces, profiles,
+projections, evidence, and architecture states; and exposes a stable CLI for
+people, CI, skills, and agent harnesses.
 
-npx yarramate check .yarramate/workspace.yaml
-npx yarramate ask .yarramate/workspace.yaml
-```
+Optional adapters provide LikeC4 visualization from semantic projections,
+Graphify observations as evidence overlays, and separately governed
+compatibility profiles for external languages. Core depends on none of them.
 
-The CLI is seven verbs, one per lifecycle stage:
+YarraMate is not affiliated with or certified by The Open Group. ArchiMate®
+is a registered trademark of The Open Group. LikeC4 and Graphify are
+independent projects; their mention does not imply affiliation or
+endorsement.
 
-```text
-init → design → apply → ask → check → reconcile → export
-create  fill    write   read  gate    drift       derive
-```
+## Development
 
-When developing the repository, build and invoke the same executable surface:
+Requirements: Node.js 22 or newer, Corepack.
 
 ```sh
-pnpm build
-
-node dist/cli.js init .
-node dist/cli.js design .yarramate/workspace.yaml
-node dist/cli.js apply operations.yaml .yarramate/workspace.yaml
-node dist/cli.js ask .yarramate/workspace.yaml
-node dist/cli.js ask .yarramate/workspace.yaml "free text about the model"
-node dist/cli.js ask .yarramate/workspace.yaml --subjects
-node dist/cli.js ask .yarramate/workspace.yaml --advise "a design question"
-node dist/cli.js ask .yarramate/workspace.yaml --where "compiler"
-node dist/cli.js check .yarramate/workspace.yaml --json
-node dist/cli.js reconcile .yarramate/workspace.yaml
-node dist/cli.js export graph .yarramate/workspace.yaml
-node dist/cli.js export briefs .yarramate/projections/context.yaml .yarramate/workspace.yaml --out handoff
+corepack enable
+pnpm install --frozen-lockfile
+pnpm run verify
 ```
 
-`init` creates `.yarramate/architecture/main.yaml` and
-`.yarramate/workspace.yaml` and delivers the agent pointer. `design`
-serves the top open design question; `apply` lands answers as one
-validated atomic batch; `ask` is every consumed-now read; `export`
-derives persisted artifacts. `check --strict` additionally fails when
-any evidence observation contradicts the model, for gates that want one
-knob. The full contract is
-[docs/AGENT-INTERFACE.md](docs/AGENT-INTERFACE.md).
+The full CI command runs typechecking, tests, native self-validation, LikeC4
+generation, and LikeC4 validation. Useful focused commands: `pnpm build`,
+`pnpm test`, `pnpm typecheck`, `pnpm self:check`, `pnpm self:reconcile`,
+`pnpm self:check:likec4`, `pnpm docs:dev`.
 
-For a local consumer test, create a package artifact:
+```text
+src/                 compiler, CLI, graph, and adapter sources
+schema/              normative JSON Schemas
+test/                tests and acceptance fixtures
+skills/              portable architecture workflow for agent harnesses
+.claude-plugin/      plugin marketplace manifest offering that skill
+docs/                contracts, guides, and decisions
+.yarramate/          canonical dogfooded architecture
+.yarramate-out/      reproducible generated output (ignored)
+```
+
+When developing the repository, build and invoke the same executable
+surface: `pnpm build`, then `node dist/cli.js <verb> …` mirrors every
+command above. For a local consumer test:
 
 ```sh
 pnpm pack --pack-destination /tmp/yarramate-package
@@ -174,16 +227,13 @@ npm install --global /tmp/yarramate-package/yarramate-*.tgz
 yarramate --help
 ```
 
-See [Consuming YarraMate](docs/CONSUMING-YARRAMATE.md) for the packaged CLI,
+The [documentation index](docs/README.md) links the public guides and
+maintainer material. Start semantic work with the
+[product contract](docs/PRODUCT-CONTRACT.md) and
+[glossary](docs/GLOSSARY.md). See
+[Consuming YarraMate](docs/CONSUMING-YARRAMATE.md) for the packaged CLI,
 schemas, agent skill, and optional adapters.
 
-In Claude Code, this repository is its own plugin marketplace:
-
-```sh
-/plugin marketplace add yarrasys/yarramate
-/plugin install yarramate-architecture@yarramate
-```
-
 ## Library API
 
 The typed library exposes the same deep compiler seam:
@@ -197,27 +247,15 @@ const result = compileWorkspace([
 ```
 
 `compileWorkspaceWithProfileContext` additionally returns resolved profile
-lineage for operations that explicitly require kind ancestry. Graph v2 remains
-the stable, graph-only interchange result.
-
-Normative schemas are available through package exports such as:
-
-```text
-yarramate/schema/document
-yarramate/schema/profile
-yarramate/schema/workspace
-yarramate/schema/graph-v2
-yarramate/schema/projection
-yarramate/schema/evidence
-yarramate/schema/core-contract
-```
-
-Optional adapter entry points are exported from:
-
-```text
-yarramate/adapter/likec4
-yarramate/adapter/graphify
-```
+lineage for operations that explicitly require kind ancestry. Graph v2
+remains the stable, graph-only interchange result.
+
+Normative schemas are available through package exports such as
+`yarramate/schema/document`, `yarramate/schema/workspace`,
+`yarramate/schema/graph-v2`, `yarramate/schema/projection`,
+`yarramate/schema/evidence`, and `yarramate/schema/core-contract`. Optional
+adapter entry points are exported from `yarramate/adapter/likec4` and
+`yarramate/adapter/graphify`.
 
 ## Contributing and security
 

package/catalogues/core-enrichment.yaml

@@ -1,6 +1,6 @@
 format: yarramate/question-catalogue/v1
 id: core-enrichment
-version: "0.5"
+version: "0.7"
 profile: yarramate/core@0.1
 presentation:
   title: Core enrichment interview
@@ -53,6 +53,9 @@ questions:
           - yarramate/core@0.1#outcome
     question: >-
       What outcome justifies this system's existence?
+    askPlain: >-
+      What would success look like for this system? What should be
+      different in the business because it exists?
     materiality: >-
       Without a declared goal or outcome, no alternative can be selected or
       rejected on grounds anyone can review; every later trade-off becomes
@@ -73,6 +76,9 @@ questions:
           - yarramate/core@0.1#driver
     question: >-
       Which stakeholders and drivers shape this architecture?
+    askPlain: >-
+      Who cares about this system, and what outside pressures are
+      pushing on it: customers, regulators, costs, deadlines?
     materiality: >-
       Drivers decide which qualities dominate when requirements conflict;
       unstated drivers get re-litigated in every review.
@@ -92,6 +98,9 @@ questions:
           - yarramate/core@0.1#requirement
     question: >-
       Which constraints and requirements are non-negotiable?
+    askPlain: >-
+      What are the hard rules here? Is there anything we absolutely
+      must do, or must never do, no matter which option we pick?
     materiality: >-
       Non-negotiable constraints eliminate alternatives outright; discovering
       them after design selection invalidates the selection.
@@ -116,6 +125,9 @@ questions:
     question: >-
       Nothing realizes {subject.name}. What fulfils it — or is it
       aspirational?
+    askPlain: >-
+      Nothing in the plan currently delivers "{subject.name}". What is
+      going to get us there? Or is it more of an aspiration for now?
     materiality: >-
       An unrealized goal either reprioritizes the roadmap or should be
       declared aspirational so it stops steering design.
@@ -124,7 +136,10 @@ questions:
       Add realization relationships from the fulfilling capability or
       service, record the aspirational status in the goal's description,
       or retire the goal (status: retired) to record that it no longer
-      steers design.
+      steers design. A goal may also be authored retired from the start:
+      status retired with the rationale in its description is the
+      declared non-goal record, and exports render it under a Non-goals
+      heading (ADR 0073).
 
 
   - id: goal-no-driver
@@ -146,6 +161,9 @@ questions:
           - yarramate/core@0.1#stakeholder
     question: >-
       What pressure produces {subject.name}?
+    askPlain: >-
+      Why is "{subject.name}" a goal at all? Who or what is pushing
+      for it?
     materiality: >-
       A goal with no driver behind it cannot be reprioritized when the
       environment changes; it floats free of the forces that would retire
@@ -169,6 +187,9 @@ questions:
         direction: outgoing
     question: >-
       What does {subject.name} actually push on?
+    askPlain: >-
+      We say "{subject.name}" matters. What would we decide differently
+      because of it? If nothing, does it belong in this conversation?
     materiality: >-
       A driver that influences nothing cannot participate in any trade-off;
       it is context theatre until it points at a goal or principle.
@@ -192,6 +213,9 @@ questions:
         direction: any
     question: >-
       What does {subject.name} care about here?
+    askPlain: >-
+      What does {subject.name} actually care about in all this? What
+      would make them push back, and what would make them happy?
     materiality: >-
       A stakeholder with no stated concern cannot veto or endorse anything;
       their objections will arrive as surprises at review time.
@@ -215,6 +239,9 @@ questions:
     question: >-
       Nothing realizes {subject.name}. What will fulfil it — or is it
       out of scope?
+    askPlain: >-
+      Who or what is going to make "{subject.name}" happen? Or should
+      we agree to drop it?
     materiality: >-
       An unrealized requirement is either unplanned work hiding in plain
       sight or scope that should be explicitly declined; both change the
@@ -224,8 +251,11 @@ questions:
       Add realization from the fulfilling service, component, or
       behavior; to descope instead, retire the requirement (status:
       retired) — retirement preserves the decision on record and closes
-      the question (ADR 0064). Delete only when the history itself is
-      noise.
+      the question (ADR 0064). Descoping at inception is the same
+      motion: a requirement authored with status retired, rationale in
+      its description, is the standing non-goal record and exports
+      render it under a Non-goals heading (ADR 0073). Delete only when
+      the history itself is noise.
 
   - id: principle-unapplied
     wave: motivation
@@ -242,6 +272,9 @@ questions:
         direction: any
     question: >-
       Where does {subject.name} bite?
+    askPlain: >-
+      Where does the principle "{subject.name}" actually change how we
+      work? Can you point to a decision it has shaped, or would shape?
     materiality: >-
       A principle applied nowhere constrains nothing; naming what it
       influences is what makes it enforceable in review.
@@ -261,6 +294,9 @@ questions:
       - condition: isolated
     question: >-
       What does the finding {subject.name} bear on?
+    askPlain: >-
+      We recorded the finding "{subject.name}". What does it actually
+      tell us, and what should change because of it?
     materiality: >-
       An assessment that touches nothing changes no decision; link it to
       the driver or goal it evaluates or drop it.
@@ -284,6 +320,9 @@ questions:
     question: >-
       Has an accountable reviewer accepted {subject.name} as adequately
       stated?
+    askPlain: >-
+      Is everyone happy with how "{subject.name}" is written up? Who in
+      this room is willing to put their name on it as correct?
     materiality: >-
       Linkage proves the wiring exists; only a recorded judgment says the
       words are right. Without an attestation, adequacy is nobody's
@@ -311,6 +350,9 @@ questions:
         direction: outgoing
     question: >-
       Who or what consumes {subject.name}?
+    askPlain: >-
+      Who actually uses "{subject.name}"? If we cannot name anyone,
+      why do we offer it?
     materiality: >-
       A service with no consumer is either the system boundary stated
       implicitly, missing model detail, or scope to delete.
@@ -334,6 +376,9 @@ questions:
         predicate: yarramate/ownership/owner
     question: >-
       Who is accountable for {subject.name}?
+    askPlain: >-
+      If something goes wrong with "{subject.name}", whose desk does
+      it land on?
     materiality: >-
       Ownership decides who accepts changes, budgets maintenance, and
       adjudicates constraint conflicts for the subject.
@@ -357,6 +402,9 @@ questions:
         direction: outgoing
     question: >-
       What behavior is {subject.name} actually responsible for?
+    askPlain: >-
+      What does {subject.name} actually do in this picture? What work
+      are they on the hook for day to day?
     materiality: >-
       An actor with no assignment is either decorative or hiding an
       undeclared responsibility boundary.
@@ -381,6 +429,9 @@ questions:
         direction: any
     question: >-
       Which behavior creates and maintains {subject.name}?
+    askPlain: >-
+      Where does "{subject.name}" come from? Who creates it, and who
+      keeps it up to date?
     materiality: >-
       Information nothing accesses cannot be owned, persisted, or exchanged
       correctly; write responsibility determines consistency boundaries.
@@ -401,6 +452,9 @@ questions:
           - yarramate/core@0.1#technologyService
     question: >-
       What does this system offer its environment, and to whom?
+    askPlain: >-
+      In plain terms: what does this system do for people, and who are
+      those people?
     materiality: >-
       Declared services define the solution boundary; without them the model
       cannot say what is inside versus outside.
@@ -429,6 +483,9 @@ questions:
           - yarramate/core@0.1#outcome
     question: >-
       Which requirement or goal does {subject.name} exist to satisfy?
+    askPlain: >-
+      Why do we have "{subject.name}" at all? If we dropped it
+      tomorrow, which goal or promise would suffer?
     materiality: >-
       A service with no motivation link cannot be traded off against
       anything; when budgets tighten nobody can say what breaks if it
@@ -453,6 +510,9 @@ questions:
         direction: incoming
     question: >-
       What starts {subject.name}?
+    askPlain: >-
+      How does "{subject.name}" get kicked off? Does somebody start
+      it, or does something happen that sets it in motion?
     materiality: >-
       A process nothing triggers or performs either runs on an undeclared
       schedule or does not actually happen; both are design facts worth
@@ -484,6 +544,9 @@ questions:
           - yarramate/core@0.1#capability
     question: >-
       What actually delivers {subject.name}?
+    askPlain: >-
+      We promise "{subject.name}". Walk me through how it actually
+      gets delivered today, or how it will be.
     materiality: >-
       A business service with no realizing behavior or application is a
       promise with no mechanism; the gap is where delivery estimates go
@@ -965,6 +1028,37 @@ questions:
       Add a lifecycle status claim; planned subjects should also appear in a
       target architecture state where states are used.
 
+  - id: subjects-near-duplicate
+    wave: hygiene
+    since: "0.7"
+    scope: subject
+    subjects:
+      kinds:
+        - yarramate/core@0.1#capability
+        - yarramate/core@0.1#businessService
+        - yarramate/core@0.1#applicationService
+        - yarramate/core@0.1#applicationComponent
+        - yarramate/core@0.1#businessActor
+        - yarramate/core@0.1#dataObject
+        - yarramate/core@0.1#businessObject
+    trigger:
+      - condition: near-duplicate
+    question: >-
+      {subject.name} closely resembles {counterparts}. Is this one subject
+      recorded twice, or are they genuinely different things?
+    materiality: >-
+      Identity is the first thing the model promises: one subject, one name,
+      one place to change it. Two records for one thing silently fork every
+      decision made about it, and both halves still pass check.
+    authority: human
+    resolution: >-
+      If they are the same subject, keep one and delete or retire the other,
+      moving its relationships across, and record the discarded name in the
+      survivor's aka list so the old word still finds it. If they are
+      genuinely different, say so in the model: add the counterpart's id to
+      this subject's distinctFrom list. That answer is itself a claim, so it
+      closes the question permanently and survives re-running the interview.
+
   - id: states-undefined
     wave: hygiene
     since: "0.1"

package/dist/adapters/graphify-entry.d.ts

@@ -1 +1 @@
-export { observeGraphify, type GraphifyGraph, type GraphifyObservationIssue, type GraphifyObservationResult, } from './graphify.js';
+export { observeGraphify, type GraphifyObservationIssue, type GraphifyGraph, type GraphifyObservationResult, } from './graphify.js';