Entity extraction from selected records

This specification owns window extraction, deterministic host admission, source/entity/knowledge bindings, current storage and invocation recovery. The end-to-end construction design connects extraction to cross-window organization, maintenance and carrier evaluation. Quality versions, measured scope and readiness belong to the evaluation protocol.

See the identity rules for components/instances, collections/unresolved identities, renames/versions and later corrections. Section 6 defines current contracts; only current data structures are supported, without legacy readers, recovery or migration. Human-confirmed cross-window organization is provided by the entity-link journal and library, without replacing window identities. Automatic cross-Agent identity merging is outside scope. Research, structural validation and functional completion do not establish model performance or reuse benefits.

1. User outcome and scope

Users inspect which objects selected records discuss, which mentions refer to the same object, and which remain uncertain. Multiple knowledge candidates reference the same analysis. People, files, systems, rules, concepts, and plans can be entities; subject and object are statement roles. See How OMK understands knowledge.

Current scope covers one immutable source window. Matching names, paths, types, or similar wording do not establish identity. It does not automatically merge across logs, build a global entity database, or infer a graph. Identifying an object does not verify statements about it.

Users keep the select-records → extract entry point. Results and history provide optional entity inspection and correction, including runs with no knowledge candidates. Entity review is not a mandatory extra step.

The workspace entity catalog is a query projection of existing window analyses, not a canonical cross-log identity registry. Studio and CLI search current entities, mentions, qualifiers, and origins while preserving analysis/entity/revision identities; exact revisions support history inspection. Linked knowledge counts only current knowledge revisions and exposes their actual entity bindings and subject/object roles. Older bindings, discard choices, and unavailable sources remain visible without implying verification.

Knowledge principles own object meaning and semantic-category concepts; this page specifies current window, identity, and reference rules.

Studio presents meaning, qualifiers, ambiguity, source mentions and linked knowledge first. Referent levels and component/collection links remain in expandable details; existing special levels or links are initially expanded in correction forms.

2. Research and decisions

Primary source	Relevant practice	OMK decision
End-to-end Neural Coreference Resolution (2017)	Spans and context support mention and antecedent decisions.	Retain mention positions and correspondence rationale; do not resolve pronouns mechanically to the nearest name.
GLiNER (2024)	Open entity types in named entity recognition.	Keep open types; evaluate recognition separately from identity. Do not introduce another Python model dependency initially.
Joint entity-level relation extraction (2021)	Joint use of local mentions, coreference, and entity relations.	Prefer one invocation with independent results and a shared window catalog referenced by candidates. Logical boundaries do not require two invocations.
GraphRAG Dataflow	TextUnit provenance; joint entity/relation extraction; default merging by name and type.	Retain provenance; name/type merging violates OMK's homonym boundary, so do not adopt it or full graph indexing.
W3C Web Annotation	Quotes with surrounding text distinguish repeated passages.	Use exact quote occurrences selected explicitly by the model; the host computes positions and never chooses the first ambiguous match. This is OMK's selector, not complete protocol compatibility.
LLM coreference evaluation (2024)	Automatic and manual analysis examines prompts and failures.	Report structural admission separately from semantic errors against cases frozen before output.
LEA coreference evaluation research (2016)	Entity links inform coreference evaluation.	Check required links and separations independently; do not substitute entity counts or name matches. Do not claim a full LEA implementation.

These sources inform decisions; they do not demonstrate performance on OMK logs. Single invocation remains the default. The separately identified bounded retry policy permits explicitly authorized additional attempts, without claiming benefit. Measuring their benefit, cost, and failure behavior still requires fixed inputs, model, policy, and review criteria.

3. Contracts and identity

An independent entity analysis contains entities, mentions, identity ambiguity, and source limitations. Model identifiers are local to the window. The host assigns UUIDs once for the analysis, shared across candidates.

• Mentions retain exact quotes, references, UTF-16 positions, explicit/inferred basis, and correspondence rationale.
• Descriptions identify objects; qualifiers describe project, version, and environment. Substantive knowledge belongs in contextual statements with evidence.
• An unresolved mention refers to a local unknown object with possible targets and uncertainty, never an arbitrarily chosen target.
• Every entity has an admitted mention; mentions, possible targets, and statements have closed references. Empty entity and knowledge results are valid.
• Model quotes use evidenceRef, exact continuous quote, and optional zero-based occurrence, counting overlapping matches. Multiple matches require an explicit occurrence; missing or out-of-range indices are rejected. The host computes UTF-16 offsets without normalization, fuzzy matching, or model-supplied offsets. Old prefix/suffix selectors are rejected.
• Required referentKind distinguishes object, component, instance, version, collection, plan, and activity. componentRef is null or a source-backed link from an instance/version to a proposed component; collection is null except for collections and records known members, completeness, supporting mention IDs, and rationale. References remain within this analysis. Unknown membership differs from unresolved identity; candidates must have the same referent level. Duplicate, missing, or cyclic members are rejected.
• Link evidence must include an own-entity mention. A collective phrase has one mention, without copied spans for its members. Cases use only descriptive statements as actions/outcomes. Structural admission does not verify any identity judgment or statement.
• Partial rejection records individual reasons. Invalid mentions cannot support entities; invalid entities cannot support statements. Admission does not silently repair results or drop ambiguity.

Generation and itemwise review apply identity rules section 2.4: Issue/PR concepts may be entities when independently discussed, while individual numbered Issues/PRs remain work-record evidence or case context. Do not create standalone record entities or turn them into concepts by removing their numbers. This scope does not exclude other source-supported specific objects or instances; structural admission alone does not decide this semantic boundary.

Generation and itemwise review also retain referential context. Objects introduced in teaching examples, hypotheticals or counterexamples are not automatically the actual current object; matching names do not establish cross-context identity. When the source explicitly refers to the same object across a quotation, retain one identity rather than mechanically splitting on quotation marks or an example label. Preserve ambiguity when correspondence is unclear. An entity's description, qualifiers, mention ownership and rationale must be supported in that object's context; do not transfer an example's version, environment or result to the current object or invent missing qualifiers. The host keeps deterministic structural and localization checks, without a new NLP semantic filter.

When the source independently reviews, evaluates or revises a whole object, retain its identity and a mention denoting that whole. A part, contained guidance, example or property phrase is not an alias for the whole merely because its name, description or qualifiers include the owner's name. A longer name can still denote the whole; a phrase whose referent is only the part cannot cover it. Separate identities require source-supported independent objects, rather than a mechanical whole-plus-part pair for every ownership or containment relation.

Each entity description, qualifier and mention rationale makes its own source claims. Review their relationships and actor roles separately from the exact mention locator. Appearing in the same review or PR supports that association, not an otherwise unstated containment, ownership or proposal-origin relationship. basis: explicit records a direct source mention; it does not endorse the other fields or establish their factual truth. Omit unsupported assertions or preserve a genuinely unresolved relationship without inventing it.

Interpret the complete phrase in context. A source designation, complete quoted span or expression denoting the whole object does not automatically claim a complete component or canonical name. Distinguish an actually invented identifier or unsupported assertion from genuine wording ambiguity. Unknown external truth does not turn a clearly unsupported source claim into an uncertain output judgment; an unresolved interpretation does not supply passing evidence. These are semantic generation and review requirements, not keyword classifications or new host filters.

3.1 Critical sources and ordinary repeated mentions

Object identity and knowledge evidence have separate coverage obligations. Mentions select object names or actual referring expressions. The evidence links of extracted statements and their exact citations directly locate purposes, conditions, constraints, exceptions, corrections and unverified limits. Cite separate locations separately, retaining context needed to understand each judgment. An earlier name, background in the same message, access to the complete message or a rationale alone does not demonstrate directly located critical evidence.

Add a mention when that occurrence needs identity inspection. Ordinary repetitions of the same object can be omitted; repeated names already covered by accurate knowledge citations do not require additional mentions. Without knowledge candidates, retain mentions needed to recognize objects and assess identity. Explicitly adding a mention can repair an existing result's navigation, but does not establish automatic model coverage or let entity existence substitute for knowledge conditions or sources.

These are generation and itemwise review requirements. Admission continues to validate structure, references and exact positions, without guessing critical evidence from keywords or completing outputs. See evaluation section 2.2 for the targeted diagnostic.

4. Corrections and knowledge revisions

Entity analysis has immutable revisions, parent revisions, authors, timestamps, and reasons, with generation/head checks and idempotent write identities. Users can reassign mentions, split/merge local objects, add omitted mentions, remove false mentions, and retain ambiguity. A mention identity cannot move to different source text; relocation creates another mention. Studio explicitly corrects level, component links, collection members/completeness and evidence. Field changes do not silently remove other information; inconsistent drafts must be corrected. Before merging/removing entities or reassigning mentions, explicitly correct dependent component, membership, candidate and evidence references. The UI lists dependent entities for inspection; it does not drop references or infer membership completeness. Before merging, explicitly remove the original entity's own link information and inspect the target; removal deletes its own information but does not rewrite other entities. Original revisions and source snapshots remain preserved.

Knowledge grounding binds an exact analysis revision. Later corrections do not overwrite old knowledge. Applying a correction requires checking statement roles and evidence, and produces another knowledge revision. Splitting an old object does not let the workflow pick one replacement subject arbitrarily.

Both ordinary knowledge revision and applying an entity revision accept explicit citationLocators, a complete replacement array for the new knowledge revision's citations. Each item contains evidenceLinkId and selection: { evidenceRef, quote, occurrence? }; omitting the input preserves prior citations still referenced by the draft. An explicit empty array is invalid. One evidence link may have several exact spans; all evidence links still need citations from matching sources, and links absent from the current draft are invalid. Locators stay within the original entity analysis snapshot/sourceVersion. The application reads frozen source text, computes UTF-16 positions using the exact occurrence rules in §2, then validates the complete grounding reference closure; storage reference validation cannot replace source localization. Invalid structure, positions or references produce the bounded knowledge_citations_invalid code. Unavailable sources or concurrency conflicts also append no revision.

CLI revise/apply-entities use a --citations locator JSON file; corresponding HTTP operations use citationLocators, and Studio shares the same editing and application workflow. The four-field draft, grounding v2, original generation outcome and historical readers keep their contracts; no data migration is needed. New citations belong only to the new knowledge revision, do not change original run birth statistics, and do not establish semantic correctness. The new revision still needs item-level review and a maintenance decision.

If a previous analysis extracted individual Issue/PR records as entities, correct the entity catalog explicitly in a new analysis revision after reviewing dependent references. Do not rename those records into concepts or reuse their UUIDs with a changed meaning. Then revise affected knowledge statements, subject/object bindings and citations individually, using source-supported subjects and retaining record identifiers, links, status and attribution in citations or context. Review retention again for the new knowledge revision. If no supported reassignment exists, retain the old binding with its limitation until an explicit revision or discard decision. Original analyses, knowledge revisions, sources and outcomes remain unchanged; a changed extraction scope does not automatically migrate or rescore them.

Corrections remain human or agent judgments, not automatic truth verification, and do not inherit retention decisions. Deleted or unreadable sources remain explicitly unavailable; saved quotes alone do not establish that original text was checked again.

Applying entities preserves prior additional identity uncertainty notes by default; users may explicitly review and change them, while historical notes remain in old revisions. Current catalog uncertainties are mandatory and cannot be erased with empty input. Inspect statement conditions, exceptions, and unknowns separately; renaming or merging entities does not delete them automatically.

5. Domain and runtime boundaries

knowledge is the umbrella domain for knowledge construction and maintenance. Root TypeScript modules, entities/, and entity-library/ own pure contracts, references, and revision invariants. knowledge/extraction owns selected windows, model protocols and output admission; knowledge/application owns shared use cases, and knowledge/adapters implements model transport, source reads and file storage. Studio and CLI share the workflow. Observability supplies source facts; Evaluation Core does not own observed entities or filesystem effects.

Entity domain code lives in src/knowledge/entities/: contracts.ts defines entity analyses and storage ports, identity.ts defines identity rules, links.ts and link-invocation.ts define the cross-window review and invocation contracts, validation.ts checks analysis references and mentions, and history.ts handles immutable revisions and deterministic write rules. Consumers import by responsibility directly; this module does not invoke models, read or write files, or depend on Studio. knowledge/extraction admits model output, knowledge/application orchestrates joint entity/knowledge extraction, and knowledge/adapters implements entity file storage. Cross-window invocation execution remains in knowledge/entity-linking. These execution subdomains retain their existing runtime and type-only relationships; the umbrella does not imply a purely inward dependency graph. Directory boundaries add no model invocations or user steps.

Each v5 run defaults to knowledge-generation-single/v1: one OMK invocation. The explicit knowledge-generation-bounded/v1 policy permits at most three invocations, including at most two validation reasks, without fallback. Before every dispatch, persist exact system/input digests, source bindings, prompt/wire/pipeline identities, producer reservation and, for bounded policy, its non-refundable token reservation and trigger. The API producer proof additionally binds the actual rendered body digest and endpoint; this is not a complete request-byte archive or a record of unseen Codex global context. Archive the complete returned executor JSON or a bounded exception observation in an immutable outcome sidecar before structural decoding, admission and preparation of entity/knowledge write intents. Failed partial output, the separate refusal channel, usage/cache fields and their reported flags, internal attemptCount and stop/failure diagnostics remain original evidence; they are not replaced by a display error. This does not capture raw provider HTTP or CLI transport, establish provider-request counts, or prove that a normalized zero was explicitly reported. Authored model-port projections retain their narrower declared evidence scope.

Recovery archives an outcome still held by the same application instance, reads an already persisted sidecar, or finishes allocated idempotent write intents without invoking the model again. Commit entities before knowledge. A started invocation without saved outcome bytes remains unknown after process loss; it does not authorize a resend or refund. Repeating generate with the same run identity also only recovers; it does not restart the retry scheduler.

The bounded policy freezes maxInvocations, maxReasks, profileId, maxTotalTokens, maxOutputTokens, retry/backoff, feedback and selection rules. Validation reasks consume the same invocation limit. Only classified rate-limit/server/network/timeout failures and parse/wire/envelope or zero-admission results can lead to another attempt; any admitted sibling selects the partial result. Archive and commit failures cannot trigger a new model call. Each attempt reserves the full verified input/output upper bound, without refund for lower or unknown reported usage; standardized input, cache-read, cache-creation and output buckets are observed separately. Unsupported budget profiles fail before dispatch. The production profile requires the exact official API endpoint and snapshot, while Codex remains supported by the default single policy. This introduces a separate policy/measurement identity, not a new prompt or response Schema, model-quality evidence, or automatic provider fallback.

Only selected excerpts and scope limitations are sent. Native paths stay local; instructions in logs cannot expand reading or invoke tools. Unreported cost is unknown, not zero.

6. Current storage contracts

entities/<analysis-id>.json uses entity-analysis-history v2 with immutable entity revisions, source bindings, and write receipts. items/<identity-digest>.json uses knowledge-item-history v2; knowledge generated by this extraction workflow binds grounding to an exact entity analysis revision.

An entity history contains at most 1,024 revisions, including its initial analysis, and each file is limited to 16 MiB. A matching committed requestId and digest is returned before history/file capacity checks. A new append to a history already containing 1,024 revisions, or one that would exceed the file limit, is explicitly rejected before publication; CLI and Studio use the existing knowledge_capacity_exceeded diagnosis. Reduce the new content for a file-size refusal; reducing a draft cannot free a full history. Old revisions are never automatically truncated, deleted or overwritten. This change does not classify uncertain read/I/O failures as known pre-publication capacity refusals.

Entity history v2 keeps commandDigest as a nonempty opaque idempotency token; the file adapter generates SHA-256 from the canonical actor and command. This change does not tighten existing read formats, recompute digests or upgrade the entity history version, and digest format checking is not cryptographic authentication of arbitrary historical tampering. Catalog scan limits on file count/total bytes remain separate from these per-record write limits; no workspace-wide write quota is added.

extraction-runs/<run-id>.json uses knowledge-extraction-run v5. Immutable native outcomes live at extraction-runs/outcomes/<run-id>/<attempt-id>.json; run metadata binds their identities/digests, admission facts and stable entity/knowledge write intents. Both metadata and outcome capacity must be admitted before dispatch. The existing response guard uses JavaScript string length with a ceiling of 2 × 1024² code units; it limits admission after complete outcome archival rather than truncating native evidence. New readers validate the current format and exact references instead of accepting a v4 file placed in the new directory.

Automatic extraction keeps existing permission fields at Schema v1. A missing policy explicitly means the existing single-invocation authorization. New permissions may record the selected policy and conversation-invocations/v1 ledger identity; immutable per-attempt receipts bind permission/run/attempt/request identities and any full token reservation before dispatch. Mutable call/token counters reconcile from those receipts without refunds. The conversation's maxCalls and bounded token allowance accumulate across windows; every retry/reask consumes another slot. A new policy requires fresh user approval, without widening or rewriting an old grant.

The explicit human sealing operation is a separate BREAKING-SCHEMA boundary: knowledge-extraction-seal-intent v1 and knowledge-extraction-seal-marker v1 do not upgrade or reinterpret run v5 or an older run Schema. omk observe knowledge sealed-runs --workspace /absolute/workspace --id <run-id> --json first inspects an exact candidate and returns expectedManifestDigest, expectedInventoryDigest, and the raw file inventory. seal-run requires those SHA-256 identities, a stable --operation-id, declared human --operator, and --reason; it requires an explicit workspace and does not resolve global settings or construct a producer. --storage-namespace legacy explicitly selects runs/; it is never scanned as a supported run format. Opaque older envelopes also require --offline, a declaration that relevant old writers have stopped or are offline, not verified process-exit evidence. Replays must retain the identical operation, actor, reason, namespace, and evidence identities. Parameter failures exit 2, business/unknown I/O failures exit 1, and a confirmed seal or successful query exits 0 without implying semantic acceptance.

A current-format candidate must use an old strict wire on every attempt, have exact archives for every registered attempt including the final attempt, and have no unregistered sidecars. Prepared/completed runs, entity intents, knowledge intents, committed writes, and an existing entities/<run-id>.json are refused. Missing or corrupt archives and unknown I/O are refused. Native output is not passed through today's decoder/admission. Unsupported Schema 1–4 envelopes are recognized only to preserve opaque manifest bytes and the selected namespace's existing outcomes/<run-id>/<attempt-id>.json inventory; their internal state, reservations, exits, calls, and costs are not interpreted or certified. The inventory is bounded to a 16 MiB manifest and at most 64 sidecars, each at the existing outcome ceiling; it cannot certify unknown external/legacy files outside those paths or future returns.

The per-run transaction stores extraction-runs/seals/<current|legacy>/<run-id>/intent.json and byte-identical evidence/manifest.json plus evidence/outcomes/<attempt-id>.json. The original manifest includes its original reservation bytes; sidecars are copied without reserialization. An immutable intent establishes operation ownership before copies; after all copies and intent have durable file/directory confirmation, the workspace write guard rechecks the exact source manifest/inventory identities and atomically replaces the original manifest path with its bound marker. The original path remains occupied and original bytes remain in evidence. A pending intent without that marker is not sealed and blocks normal execution/recovery; same-operation replay completes or reconfirms durability. Failure preserves published evidence and the original or marker rather than pretending to roll back an uncertain publication. Current and older readers reject a marker as a runnable manifest. There is no unseal, migration, compatibility reader, model invocation, entity/knowledge write, or automatic new run. The guard cannot stop an unknown older process holding a prepared record in memory; an offline declaration does not prove remote work stopped or guarantee archival of its later return. Filesystems without required file/directory fsync, exclusive publication, or atomic rename fail explicitly; this is not a power-loss experiment or multi-file transaction guarantee.

Extraction quality is explicitly omk.extraction-quality/v4: current-namespace sealed runs remain in runCount; readable original manifests remain in their original group as sealedUnknown with unknown admission denominators, and unsupported originals are counted as ungrouped seals. Legacy seals are separately counted outside current denominators. Pending intents are separately visible and are not sealed. CLI/Studio show human disposition and execution unknown, never success, known billing, or semantic acceptance. Seal listings read manifests/intents/markers only and say evidenceIntegrity: not_checked; they do not claim renewed native-archive verification. Explicit same-operation sealing replay rechecks every preserved evidence byte and durable acknowledgement. No historical study or user data is sealed or rescored by installing this feature.

Default configured generation uses strict knowledge-extraction-v30: the strict rendering includes eight complete, AI-author-reviewed synthetic input/output demonstrations and an explicitly separate host partial-admission diagnostic. The diagnostic reuses the release-gate example: a sibling with a nonmatching quote is rejected while the valid sibling remains admitted. The intentionally bad sibling is diagnostic material, not a correct-output template. These already viewed demonstrations are not an evaluation split or evidence of semantic improvement. The single wire Schema and nullable-placeholder decoding remain unchanged before existing host admission checks; the domain response remains Schema v4. Current authored model ports use prompt-json knowledge-extraction-v29; historical prompt-json v14 and strict v18 retain their original bytes. Storage v5, prompt versions, wire identity, rendered request and pipeline policy have separate provenance. Unsupported capabilities fail before dispatch, without silent prompt-only fallback. Different content or configuration cannot reuse a runId.

Quality acceptance uses the current guide, corpus and checker identity. Changes to prompt, annotation or tool bytes require a new measurement identity; old reports, raw outputs and scores are not recalculated. Reproduce other versions only at their corresponding frozen revisions, without combining them with the current runtime.

The v19/v20 scope change in section 3 is BREAKING-COMPARABILITY. It changes prompt bytes and the annotation guide/corpus identity, without changing wire/domain Schemas, storage formats or pipeline policies, and adds no post-generation blacklist. The five demonstration texts remain byte-identical to the historical v4 bundle; the full v20 strict system has a changed rule prefix and is not that bundle's frozen v18 candidate. Current requests require a fresh run identity and matching execution permission; old outputs and maintenance decisions do not become current-policy results.

The v21/v22 temporal guidance correction and sixth demonstration are BREAKING-COMPARABILITY. A message timestamp records source time rather than automatically supplying occurredDuring or validDuring. Unsupported status and future normative times remain unknown; explicitly stated event times retain their supported precision, including a time equal to the message timestamp. The first five demonstrations retain their serialized bytes. New versions avoid reusing the published strict v20 name for different prompt-json bytes. Collection scope, public Schemas, wire, storage and pipeline policies do not change, and the host adds no timestamp-equality blacklist or rewrite to unknown. The guidance affects only new requests: old outputs, revisions, maintenance decisions and scores stay unchanged and are not rescored or pooled with new outputs. Structural/wiring tests do not establish model compliance or guarantee that all temporal errors are fixed; actual effects require a separately frozen validation plan.

The v23/v24 referential-context guidance and seventh complete wire demonstration are BREAKING-COMPARABILITY: the new prompt and demonstration bytes require a new measurement identity, while the first six demonstrations retain their serialized bytes. The motivation was an old output from one seen real development window that transferred an example object's version qualifier to the current object. This is a defect cue from a particular output, not a population error rate. Wire, public Schemas, storage, collection scope, pipeline policies and invocation counts remain unchanged; old runs are not migrated or rescored, and their original scores are not recalculated. The new synthetic context diagnostic is separate from the 64-case corpus. Authored-response regressions and prompt demonstrations do not establish that real v24 output is fixed or stably better; actual effects still require a frozen real comparison and itemwise review.

The v25/v26 core-object guidance and eighth complete wire demonstration are BREAKING-COMPARABILITY. A content object independently evaluated or revised in the source cannot be replaced by the file, page or location that contains it; when both are independently discussed they keep their supported identities. Containment alone does not require splitting every section or example into an entity. The first seven demonstrations retain their serialized bytes. This correction follows one omitted learning-example object in a repeated run on a seen real development window: emitting its source file and mentioning the example in the file description did not cover the example identity. This is a particular omission cue, not an error-rate estimate. Existing guide/scoring identities, the 64-case corpus, wire, public Schemas, storage and single-invocation policy stay unchanged. A separate synthetic diagnostic checks required-content omissions, unsupported splitting and explicit aliases using existing checks; authored responses verify the engineering checks rather than real-model improvement. Old plans and results remain unchanged; new requests require new identities and itemwise real validation.

The v27/v28 clarification of reviewed wholes and their parts is BREAKING-COMPARABILITY: rule bytes and the output self-check within the same invocation change, while all eight complete wire demonstrations retain their bytes; no demonstration or invocation stage is added. Registered raw-byte constraints for v19 through v26 remain enforced. Guide v11, checker v5, the 64-case/212-critical-mention corpus, wire, public Schemas, storage and single policy do not change. The motivation remains a whole-object omission in seen development diagnostics, not evidence of stable improvement. New bytes require a separately frozen measurement identity, engineering verification and itemwise real-output review; old runs and scores are not recalculated.

The v29/v30 source-claim guidance and output self-check within the same invocation are BREAKING-COMPARABILITY. They require source support for descriptions, qualifiers and mention rationales separately, without mechanically interpreting wording about a whole or a complete span as a canonical-name claim. All eight wire demonstrations and the registered v19–v28 raw-byte digest constraints stay unchanged. Guide v11, checker v5, the 64-case/212-critical-mention corpus, public Schemas, wire, storage and single policy remain unchanged; no invocation stage is added. Seen development findings motivate this increment but establish neither real-model compliance nor stable improvement. New prompt and guide-page bytes require a newly frozen measurement identity and itemwise review; historical outputs, scores and frozen packages are not rewritten.

Ordinary generation and the current reader leave former runs/ v4 files untouched: they do not decode, migrate, rewrite or delete them. The explicit opaque sealing operation above is the sole exception: with an offline-writer declaration, it preserves original bytes and inventory before replacing the original entry with a versioned marker; it never adds a legacy semantic reader. Legacy run details, resume, conversation/project batches and current quality statistics remain unavailable. Current sources/, entity history v2 and knowledge history v2 remain readable in the same workspace, including their bindings; a new empty workspace is not required. Entity history v1 remains unsupported independently of this run upgrade. New extractions never automatically take over old knowledge bindings.

The historically recorded raw UTF-8 digest for the full strict v16 system is sha256:a8c353c0f9c05d1249c3414eaaba7bc7d85b0d34f98142413ba6550173bde6e7. This is a historical digest declaration: the current tree has neither a corresponding complete v16 prompt artifact nor a v16 entry in test/measurement-governance/prompt-registry.ts and its freeze test. It therefore does not provide a recomputable byte-level anchor for that value; a recorded version or digest alone cannot restore the original system bytes. That historical prompt change is BREAKING-COMPARABILITY, without changing wire/domain Schemas, run storage or pipeline policies. Historical no-few-shot strict v15 retains frozen digest sha256:d5c14bb7809a2ccd57b5984bb39ff14ef709fd365db8df7792b697fac420736d; original prompt-json v14 retains sha256:e3acd05eca278b0e34f5d8b75767176c5ede7ce7fade561975eb1f4e4c417399. Old frozen assets, experiment arms, permissions and results retain their original identities; v16 cannot reuse an old runId or execution permission. Existing data is not migrated or rescored, and different identities cannot be pooled or inherit quality/Gold conclusions. Actual quality and execution evidence remain in the evaluation protocol.

Writes serialize through the workspace's .knowledge-write.lock. Only a local PID proven exited by SIG0 returning ESRCH permits recovery; lock age and run status are insufficient. Recoverers serialize by the original owner identity to avoid deleting a later live lock. Interrupted recovery guards follow the same rule.

The entity catalog reads current entities histories without writing duplicate entities or a persistent index. Corrupt, unsupported, and symlink files count as unreadable analyses; healthy analyses remain searchable with an explicit incomplete-result notice. One scan allows at most 4,096 JSON files and 64 MiB total file size, then fails rather than silently truncating. Queries default to 20 entities per page, allow at most 100, and sort by revision time and stable identities. Unreadable linked knowledge makes counts unknown, not zero. Unavailable sources prevent correction.

7. Quality and completion evidence

Functional verification covers independent entity results, inspection/correction, shared knowledge identities and exact revision bindings, empty/partial/interrupted behavior, and rejection of unsupported formats. The evaluation protocol alone owns frozen quality criteria, checker/corpus/guide identities, model comparisons, review gates and current evidence. Location and reference closure establish structure, not semantic accuracy, truth or reuse benefit; workflow tests cannot replace that protocol.