Arcanada — Meaning Management in Autonomous AI Systems: the Knowledge Contract Architecture

I. Problem, Boundaries, and Contribution

Abstract

The available sources are heterogeneous: queries, search results, memory, instructions, tools, Policy, and model assumptions together form the available context, yet they do not automatically determine which task-specific semantic commitment has been selected, how it was issued, what realizes it, or whether a particular action is permitted.

The central contribution is Meaning Management as an architectural layer governing the lifecycle of task-specific semantic commitments. The selection is fixed by a Resolution Receipt; the Knowledge Contract is separated from issuance; post-issuance Binding is separated from the current Authorization. Variant A, the BKG, the Resolver, the identity model, Expansion/Evolution, and the execution gate formally specify the mechanisms that support this decomposition.

The surveyed purposive corpus covers prompting, retrieval, memory, orchestration, provenance, workflows, policy evaluation, and knowledge representation individually, but provides no single model of this governed transition; the finding is bounded by the corpus and asserts no historical priority. Practical usefulness is tested by nine hypotheses and nine protocols, HYP/EXP-001–009. The experiments have not been run, so error reduction, improved diagnosis, and acceptable cost are not demonstrated.

Introduction

An autonomous system receives a heterogeneous semantic context: queries, documents, memory, rules, task descriptions, and available tools differ in version, provenance, evidence, and scope of applicability. Their joint presence in a prompt does not explain which statements became binding for a particular task.

When the selection of a commitment remains implicit, there is no verifiable lifecycle from candidate to accepted meaning: the alternatives, the conflicts, the Policies applied, and the grounds for the choice are difficult to reconstruct. Enlarging the context or improving retrieval does not by itself establish that boundary.

Meaning Management is introduced as the layer that forms task-specific semantic commitments and fixes them in an immutable Knowledge Contract. Context, proposals, commitments, the ResolutionCore, the Explanation, the semantic Contract, issuance, binding, and authorization-at-t are distinct; the Contract does not replace a repository, a runtime, or a policy engine.

The research question that follows is how to make this transition versionable, explainable, and auditable without conflating semantic selection, issuance, runtime realization, and authorization. The formal model states verifiable boundaries; the experimental programme admits refutation of their practical usefulness. No working implementation and no superiority over a baseline are claimed.

Diagram of the transition from a prompt-driven system through retrieval to a Knowledge Contract, with plots of conjectured properties. — **Figure 1.** A visual conjecture about the transition from retrieved context to a Knowledge Contract. The lower curves are not measured and are not a result.

Status of the Claims

Three layers of claims must be distinguished. The first layer comprises fixed design decisions: the composition of Variant A, the five Resolver stage names, the prohibition on immediate trust in synthesized knowledge, the distinction between Expansion and Evolution, and the separation of contract, binding, and authorization. The second layer comprises formalized proposals: the BKG model, the compatibility predicates, the record structures, and the experimental protocols. The third layer comprises results not yet obtained: the effect of the architecture on the number of violations, on cost, on reproducibility, and on reviewer agreement.

Definition: The normative meaning of a term within this architecture; not an empirical result.
Design hypothesis: An architectural decision whose usefulness must be tested by comparison.
Derived property: A consequence of the adopted definitions or of the formal construction under the stated premises.
Implementation proposal: One admissible way of realizing a mechanism, not a required element of the core.
Empirical observation: A result actually measured; in the current cycle this applies only to the publication package.
Untested expectation: A conjectured direction of effect that must not be read as an outcome.
Open question: A research uncertainty with no adopted answer.

The technical build of the page, the verification of source-image hashes, and the passing tests confirm only the integrity of the publication package. They do not confirm HYP-001–HYP-009, do not measure the quality of agent behaviour, and do not turn a formal specification into an implemented system. Synthetic verification of the mechanics differs from empirical validation in the same way that compiling an experimental protocol differs from executing it.

The boundary in short: available context is not permitted meaning; permitted meaning is not an executable realization; a located realization is not a permitted action; and a correctly assembled text is not a confirmed architecture.

Problem Statement

An agentic context mixes sources of differing status: an incomplete query, documents that are relevant but not applicable, stale memory, tools accessible without the corresponding authority, and plausible model proposals with no demonstrated provenance. A Policy not explicitly bound to the plan remains an external filter.

The failure arises in the transition between "the material is available" and "the system is obliged to act in exactly this way". If that transition is not represented by distinct objects and receipts, then after execution it is hard to answer:

which versions of the role, skills, plan, constraints, policies, success criteria, and capability descriptions were selected;
which source proposed each element, and which check found it admissible;
which conflicts and gaps were detected, and which could have disappeared inside a long prompt;
why a particular adapter was considered a realization of an abstract capability;
which principal was entitled to issue the contract, approve the binding, and permit the action;
whether the selection can be reproduced after the knowledge repository has changed or an authority has been revoked.

Context length, retrieval quality, and generation accuracy do not exhaust the problem: versions may conflict, a capability may have no verified realization, and an authority may be revoked after the Contract was issued. Explicit management of semantic commitments is required.

Research Question and Scope

Principal question: how can an autonomous AI system extract from heterogeneous available material a compatible, traceable, and versionable semantic cut for a particular task, fix it without retroactive modification, and at the same time avoid conflating the selection of meaning with runtime binding and with authorization of the action?

Subsidiary problems: to define the artifact types; to compute bounded transitive requirements; to distinguish absence, conflict, ambiguity, and binding failure; to evolve knowledge without rewriting history; and to enable replay and independent audit.

Conceptual exclusions

This work does not model human semantics, consciousness, internal neural representations, a general theory of machine understanding, or a universal AGI control plane.

Non-goals

The architecture does not guarantee the success of an action in the open world, the absence of external uncertainty, the availability of every runtime provider, or a complete operational replay of external infrastructure.

Implementation neutrality

The normative core does not select a graph store, RDF/SHACL, a relational database, a policy engine, an orchestrator, MCP, a CLI, A2A, a transport, a particular agent framework, or an LLM vendor.

Object of study — autonomous systems that form task-specific executable semantic commitments from versionable managed knowledge and separate those commitments from runtime realization and authorization.

Contribution of This Architecture

Primary contribution — Meaning Management as an architectural layer that makes explicit the lifecycle of task-specific semantic commitments: from available context and selection through issuance, concrete runtime realization, and the current permission for an action.

Supporting contributions:

a typed ontology of the seven managed artifacts of Variant A;
the Blueprint Knowledge Graph with bounded closure and compatibility;
the five-stage Resolver protocol;
the Resolution Receipt with its own R_id;
the immutable Knowledge Contract with K_id;
an independent issuance identity I_id;
scoped Knowledge Expansion and governed Artifact Evolution;
the separation of Binding from action-specific Authorization;
a model of semantic, decision, and operational reproducibility;
the falsifiable preregistration programme HYP/EXP-001–009.

These mechanisms make the decomposition concrete without constituting a claim of historical priority.

Direct — scholarly work that directly characterizes the mechanism or research direction being compared; Supporting — a source that supports an individual mechanism, term, or adjacent claim. This is not a quality ranking; a coincidence of words does not establish kinship.

A comparative visual conjecture about prompting, in-context learning, RAG, tool-augmented agents, and the Knowledge Contract, with unconfirmed check marks and trends. — **Figure 13.** A visual conjecture about related work, not the result of a comparison. The check marks and trends are not measured; the scholarly comparison is carried out by the table of sources and mechanisms below.

Area	Class and sources	What is already provided	Remaining boundary
Prompt engineering	Direct [1]	Typologies of task prompts.	No lifecycle of version/evidence/authority for commitments.
In-context learning	Direct [2] [3]	Context changes behaviour without retraining; its format matters.	An example is not separated from an accepted artifact/Receipt.
Retrieval-augmented generation	Direct [4]	Generation uses retrieved non-parametric memory.	Relevance does not establish compatibility/evidence/eligibility.
Agent planning and action	Direct [5]	ReAct interleaves reasoning and actions.	A trajectory is not a Contract or an Auth_t.
Multi-agent systems	Direct [6] [7]	Roles and conversations coordinate agents.	No Variant A, BKG cut, or pinned identity.
Agent memory	Direct [8] [9]	Memory, retrieval, and reflection sustain a long context.	Availability does not confer governance status.
Knowledge graphs and validation	Direct [10]; Supporting [11] [22]	Typed graphs and constraint validation.	No bounded task closure, selection Receipt, or Issue.
Provenance	Supporting [12]	Entities, activities, agents, and derivation.	Does not define an evidence threshold, an approver, or conflict resolution.
Workflow languages	Direct [13]; Supporting [14]	Portable workflows and process notation.	The steps are already given; semantic candidates are not resolved.
Software architecture	Supporting [15]; Direct [16]	Viewpoints, elements, interfaces, behavior, rationale.	A description is not a Resolver, a Binding, or an Auth.
Policy-as-code	Supporting [17] [18]	Decisions over a structured request and data.	No complete SemanticCut or binding equivalence.
Reproducible systems	Supporting [19]	Explicit source, environment, instructions, and comparison.	Semantic inputs and receipts are required; the outcome need not coincide.
Governance frameworks	Supporting [20]	Govern, map, measure, and manage AI risks.	No artifact calculus, graph cut, or Contract identity.
Semantic service descriptions	Supporting [21]	Profile, process model, grounding.	No complete Variant A lifecycle and no current Auth.

Variant A makes the decomposition concrete through typed artifacts, the BKG, the Resolver, the Receipt, the Contract, Expansion/Evolution, and the execution gate; a combination of supporting mechanics does not establish historical priority. The Receipt profiles provenance, Evidence Profiles remain a proposal, and OPA/Cedar do not substitute for semantic selection, binding proof, or authority governance.

The corpus was selected purposively. The finding is bounded by the surveyed corpus and is not a claim of historical priority. A closely related system would narrow the finding; the absence of a located object does not prove that object's non-existence. The boundaries of the 22 sources and the update procedure are deferred to the Supplement.

III. Conceptual Model

Design Principles

Design hypothesis. These principles state a testable construction, but their practical usefulness is not considered established until compared against a baseline.

Candidate first. Search, memory, model, and tool output become commitments only after Verify and Select.
Typed commitments. The seven types do not merge: the type determines fields, relations, checks, and governance.
Separate immutability. Contract bytes and issuance metadata have independent identities; a correction creates a new record.
Named failure. Missing, Conflict, Ambiguous, Evidence-Insufficient, Search-Incomplete, Unbound, and Unauthorized must not be concealed by a fallback.
No self-certification. A producer does not accept its own synthesis unilaterally; the required independence depends on risk.
Expansion ≠ Evolution. Closing a task gap does not modify the repository; Evolution creates a governed successor.
Three boundaries. The Contract states what is obligatory, the Binding states the realization, and the Auth states what is permitted now.
Receipt. An audit uses the recorded inputs and decisions, not a reconstruction of hidden reasoning.

Terminology

Definition. The terms below carry a normative meaning only within the proposed Meaning Management profile.

On a narrow screen the table scrolls horizontally.

Term	Definition in this version	Does not denote
Meaning Management	The public name of the architectural layer that converts heterogeneous and changing semantic information into managed, versionable, task-specific commitments.	A universal theory of meaning, the internal state of a model, or the name of a single software product.
Available context	All the material a Resolver may consider within the given search boundaries.	A set of already accepted truths or authorities.
Proposal	A candidate for inclusion, with its source, version, and declared type.	An accepted artifact.
Semantic commitment	The narrower formal unit of Meaning Management: a selected typed statement that enters the task cut and governs admissible execution.	Any text in a prompt, or the entire content of the available context.
Managed Artifact	A versionable object of one of the seven types, carrying identity, provenance, evidence, and lifecycle status.	A file as such; one file may encode several objects.
CapabilityDescription	A managed abstract description of a required capability, its inputs, outputs, effects, and requirements.	A concrete tool or endpoint.
CapabilityType	In Variant A this is a derived normalized type, computed from the CapabilityDescription and the graph profile for matching.	A managed artifact in its own right, or a concrete realization. A possible promotion of its status belongs to future research only.
Binding Record	A runtime record linking a commitment and a CapabilityType to an exact adapter, transport, environment, and proof of equivalence.	Permission to invoke the adapter.
Knowledge Contract	An immutable, content-addressed semantic cut of the selected versions, relations, and commitments of a single task; its identity is `K_id`.	Issuance metadata, the whole BKG, a mutable workspace, or a licence to execute.
Resolution Receipt	The audit record of the selection: the immutable ResolutionCore carries `R_id`, and the human-readable Explanation does not alter it.	A managed artifact, a Resolver stage, the Contract, or a hidden chain-of-thought.
IssueRecord	The immutable record of the issuance event within Assemble: the issuance identity `I_id` references `K_id`.	A part of `K_id`, a managed artifact, a sixth Resolver stage, or the Resolution Receipt.
AuthorityCut(t)	The proposed cut of the authorities, delegations, and revocations in force at moment t for a principal, a resource, and an action.	A complete formal model of power, a Role, or a list of environment capabilities.
PolicyCut(t)	The proposed cut of the exact Policy versions and conditions applicable to a principal, a resource, and an action at moment t.	The Policies pinned at Contract selection or issuance, or a complete policy-engine/IAM implementation.
Gap Record	A record of a deficiency with a `GapKind`: Semantic, Evidence, Version, Policy, or the operational BindingProvider.	Permission to fill the deficiency silently, or treating an authority failure as a knowledge gap.

Meaning Management is the public name of the architectural layer. A semantic commitment is the narrower formal unit. Available material acquires that status only through a verifiable selection.

Ontology of Managed Artifacts: Variant A

The formal fields, identity, and an end-to-end example of the seven types are given in Appendix A.

Let the set of managed types be T = T_primary ∪ T_operational. In the current version T_primary = {Role, Skill, Blueprint} and T_operational = {Constraint, Policy, SuccessCriterion, CapabilityDescription}. The division indicates purpose but does not establish a relation of importance: a contract can be correct only when the required instances from both groups are present.

Role, Skill, and Blueprint as the three co-equal primary reusable managed artifacts of Variant A. — **Figure 2.** The architectural classification of Role, Skill, and Blueprint as the primary reusable artifacts of Variant A. The figure's role is limited to that classification; the surrounding pipeline does not define a formal boundary of the architecture.

Primary reusable semantic artifacts

Role fixes responsibility, ownership, decision scope, governance boundary, and handoff, but does not confer access rights, authority, a profession, a job title, or the identity of the executor; a principal is authorized separately.

Skill specifies a reusable method: preconditions, inputs, strategy, outputs, effects, failures, and capabilities. It is not equivalent to a tool and does not conceal a Policy.

Blueprint connects roles and skills, dependencies, checkpoints, data, branching, and recovery. Its references initiate the closure, but do not copy the whole graph.

Operational and governance artifacts

Constraint states a checkable condition or a resource boundary; a violation renders the composition inadmissible.

Policy states a versioned governance rule over principal/resource/action, conditions, and precedence. A Constraint checks state; a Policy yields the applicable allow/deny decision.

SuccessCriterion defines the subject, procedure, threshold, timing, and uncertainty; the absence of a metric does not constitute success.

CapabilityDescription describes an abstract capability. The CapabilityType is derived by profile rules; a post-issuance Bind proves the correspondence of a concrete adapter.

Derived property. If the CapabilityDescription and the normalization rules are pinned to exact versions, the CapabilityType must be reproducible from the same inputs; this follows from the chosen status of the type, but still requires an executable conformance test.

Forbidden conflations

The following distinctions are normative invariants of Variant A. They do not depend on the chosen graph store, transport, or agent framework.

Policy != Constraint. A Policy states a governance rule and the applicability of authority; a Constraint states a checkable condition for the admissibility of a composition or a result.
Role != Authority. A Role describes responsibility; the right to propose, verify, publish, issue, bind, or execute is determined separately.
CapabilityDescription != CapabilityType. The former is a managed description; the latter, in Variant A, is derived by normalization for matching.
Expansion != Evolution. The former closes a resolution gap; the latter publishes a new reusable version after a governance process of its own.
Contract != Repository. A contract holds the exact references and commitments of a single task, not a live copy of the whole BKG.
Binding != Authorization. The correspondence of an abstract capability to a realization does not grant a principal the right to act.
Available Context != Selected Commitment. Material that has been found, retrieved, or generated remains a candidate until verification and selection.

Further prohibitions follow from these invariants: a Skill does not conceal a Policy, a Blueprint does not denote the whole repository, a Binding Record does not serve as an access token, and a SuccessCriterion is not a promise of a result. A possible promotion of CapabilityType to a managed artifact in its own right may be investigated only where it has independent ownership, governance, versioning, and lifecycle; the current ontology ascribes it no such status.

Counterexamples to architectural conflations

The architectural distinctions below are not introduced terminologically alone: for each conflation there exists a minimal counterexample in which merging the two entities leads to a loss of explainability, reproducibility, or execution correctness.

On a narrow screen the table scrolls horizontally.

Boundary	Minimal counterexample	Consequence
Available Context ≠ Selected Commitment	A retrieved Blueprint is semantically close to the task but incompatible with the current set of Policies and versions.	Presence in retrieval does not make an object a semantic commitment.
Role ≠ Authority	A principal retains the same Role, but the authority grant is revoked between t1 and t2.	A Role cannot carry a runtime permission.
Binding ≠ Authorization	A verified provider is located and `BindingValid=true`, yet `Auth_t=Deny`.	Technical realizability does not entail that the action is permitted.
`K_id ≠ I_id`	One `K_sem` is legitimately issued by two different authorized issuance events.	The semantic identity of a contract is not the identity of its issuance.
Expansion ≠ Evolution	A wholly absent Skill requires Expansion; an existing Skill with an incomplete validation procedure requires a successor through Evolution.	Creating new knowledge and issuing a new version of existing knowledge are different lifecycle operations.

Logical architectural counterexamples. They show that the distinctions are necessary within the model, but they are not empirical proof of the architecture's superiority.

IV. Semantic Architecture

The Meaning Management Lifecycle

A conceptual overview of Meaning Management: knowledge sources, the Resolver, the Knowledge Contract, and execution. — **Figure 3.** An architectural diagram — a conceptual overview of Meaning Management between the available sources and execution. It shows the distribution of responsibility but does not define the formal boundary between the Resolver, the contract, the binding, and authorization.

The object line is separated from the Resolver operations:

On a narrow screen the formula scrolls horizontally.

C_available → P_candidates → SemanticCut(q,r) → ResolutionCore/R_id → K_sem/K_id → I/I_id → B_runtime → Auth(a,t)

C_available — the materials; P_candidates — the proposals; SemanticCut(q,r) — the selected commitments; ResolutionCore/R_id — the verifiable record of the selection; K_sem/K_id — the semantic Contract; I/I_id — its issuance; B_runtime — the realization; Auth(a,t) — the decision. An arrow denotes a boundary, not trust.

SemanticCut(q,r): The selected compatible set of exact versions for task q at BKG revision r; its selection is explained by the Resolution Receipt.
BindingCut(K_id,e): The set of verified runtime realizers for the commitments of K_id in environment e; it is recorded by a separate Binding Record.
AuthorityCut(t): The addressable input cut of the authorities, delegations, and revocations in force at moment t; it is not part of the Contract and does not formalize the internal IAM model of the authority provider.
PolicyCut(t): The addressable input cut of the Policy versions and applicability conditions in force at moment t; it is not part of the Contract. This does not annul the exact Policy versions that the Contract pins as evidence of selection and issuance.

Propose creates candidates; Verify checks them; Select computes SemanticCut(q,r) and the ResolutionCore; Assemble completes semantic resolution, canonicalizes K_sem, and records the issuance I. Bind is the fifth stage of the overall protocol but a post-issuance boundary: it delegates the concrete realization to the runtime/harness. Issue is an event within Assemble, and the Receipt is a record — neither is a stage. Authorization remains outside.

Similarity therefore does not make knowledge obligatory, and a located tool is not thereby permitted.

Blueprint Knowledge Graph

Architectural construction. The BKG is a versioned typed multigraph G_r = (V_r, E_r, Π_r): a node is (artifact_id, type, version, digest, status, provenance, evidence, authority_scope), an edge is (source, relation_type, target, version_constraint, evidence, status), and Π_r holds types, compatibility, closure bounds, and precedence. RDF/SHACL and typed/property/relational/purpose-built/hybrid stores are implementation choices.

Normative scope of the name. The historical name BKG denotes the typed graph of all managed semantic artifacts; a Blueprint is a compositional node, not the only class of node.

A networked Blueprint Knowledge Graph with nodes of different types, typed relations, and a legend. — **Figure 7.** An architectural diagram of the BKG as a graph, not a tree. The underlying network shows heterogeneous nodes; the formal construction below adds versions, edge domains, invariants, bounded closure, and compatibility.

Relation types

The minimal vocabulary is requires, provides, instantiates, delegatesTo, governedBy, constrainedBy, evaluatedBy, conflictsWith, supersedes, derivedFrom. Every relation type has a domain and range; an unknown edge is not treated as safe.

Invariants

Type soundness: the type of every node is known to the profile, and the domain/range of every selected edge is admissible.
Identity integrity: the digest corresponds to the canonical bytes of the version; two distinct records do not share one identity without proven equivalence.
No dangling obligations: a mandatory edge of a selected node is either satisfied by a suitable node or raises a Gap/Search-Incomplete.
Version coherence: all version constraints in the cut are satisfied simultaneously; mutable aliases are resolved to exact versions.
Evidence and authority: the acceptance of a node and of a critical edge carries a verification receipt and an admissible approver.
Dependency termination: the relation of transitive mandatory dependencies in the task cut is acyclic, or contains an explicitly permitted iteration with a decreasing measure and a bound.
Historical stability: the snapshot G_r and the issued cut remain available after a successor appears.

Bounded closure

From the seeds S₀ the Resolver adds required dependencies and providers, the applicable Policy/Constraint, and the SuccessCriterion until a fixed point or until B = (max_depth, max_nodes, time_budget, provider_budget) is reached. The result is one of {Closed, Gap, Conflict, Ambiguous, Search-Incomplete}; exhausting B does not mean Closed.

On a narrow screen the formula scrolls horizontally.

C₀ = S₀
Cₖ₊₁ = Cₖ ∪ Required(Cₖ) ∪ ApplicableGovernance(Cₖ) ∪ CandidateProviders(Cₖ)

Compatible(C) checks types, versions, hard constraints, policy applicability, declared artifact scope, exclusions, the Evidence Profile, and the issuer. Ranking is applied only to compatible cuts; the ResolutionCore records the identities and the reason codes of rejections.

Versions and the relation to the contract

The BKG is mutable, the Contract is not: Assemble stores identities from G_r, not a live link. Published bytes are immutable; versions coexist with the statuses deprecated, superseded, and revoked; Contracts stay pinned. A future selector may only mean latest compatible approved version, never plain latest.

Neither completeness nor solver complexity is proven. Alternative providers, exclusions, and negative edges create a combinatorial search, which is why a strategy, budgets, and Search-Incomplete are mandatory; a purpose-built graph still has to be compared against RDF/SHACL [11] [22].

Resolver: Propose → Verify → Select → Assemble → Bind

A complete example of candidate resolution and the issuance boundary is given in Appendix B.

A Blueprint candidate selection pipeline from task analysis through constraint checking and ranking to the selected set. — **Figure 5.** The architectural workflow of Selection inside the Resolver. Top-N denotes a ranked set of candidates after coverage and compatibility checking, not a fixed number of Blueprints.

Propose

From the task intent, the bounds, and the BKG snapshot, the operation returns candidates with a declared type, source and version or retrieval time, producer, digest, and relevance reason. Model output remains a proposal at any confidence.

Verify

Verify checks the schema, digest, provenance, evidence, validity, relation domain/range, source authority, and the declared ExpansionArtifact scope. Verify checks scope with respect to the task, the lineage, and the namespace. The possible outcomes are Verified, Rejected, Evidence-Insufficient, Gap, Search-Incomplete, and Scope-Mismatch.

Select

Select applies precedence, exclusions, scope, and version constraints before ranking. Select rejects a scope mismatch with the state Scope-Mismatch; equally ranked cuts yield Ambiguous, and incompatible hard requirements yield Conflict.

The determinism boundary. In this paper, deterministic resolution over pinned candidates and Policy inputs means the reproducible application of frozen verification and selection rules, assembly, canonical identities, and replay. Determinism is not ascribed to the stochastic model or to the search inside Propose.

Assemble and the Issue event

Assemble completes semantic resolution: it freezes ResolutionCore/R_id and creates K_sem/K_id; then the Issue event binds K_id to an issuer, authority evidence, timestamp, and signature in a separate I/I_id record. The IssueRecord materializes I without altering K_id. Absent the right to issue, the outcome is Issue-Unauthorized.

Bind

Bind remains the fifth stage of the Resolver protocol but sits after issuance: the runtime/harness selects the adapter, transport, interface, and environment and records B_id, the equivalence evidence, and the validity. An incompatibility yields Unbound; success does not permit the action.

The original Knowledge Resolver with task analysis, artifact matching, completeness checking, a missing-knowledge branch, and contract assembly. — **Figure 6.** The architectural workflow of the Resolver with completeness checking and the gap branch. The normative sequence is Propose → Verify → Select → Assemble → Bind with typed failures.

Terminal states

A Contract is not obligatory: Missing, Gap, Evidence-Insufficient, Conflict, Ambiguous, Search-Incomplete, Scope-Mismatch, Issue-Unauthorized, Unbound, Policy-Conflict, and Unauthorized are admissible terminal states and remain in the denominator.

Resolution Receipt: the boundary between selection and issuance

After Select the system creates an immutable Resolution Receipt. It is an audit record of the selection in its own right, but neither a managed semantic artifact nor a Resolver stage. The receipt exists even when the system declines to continue with assembly: it makes it possible to distinguish a conflict, an incomplete search, insufficient evidence, and the absence of a right to issue.

ResolutionCore = canon(candidate_ids, search_bounds, selected_versions, rejection_reason_codes, precedence, conflicts, uncertainty, Search-Incomplete, policy_ids)
R_id = H(bytes(ResolutionCore))

Explanation = narrative(decision_summary, audience_profile, redactions) · E_id = H(bytes(Explanation))

ResolutionCore contains only the canonical identifiers and reason codes sufficient for a machine reconstruction of the selection. The narrative Explanation may be rephrased, translated, or redacted without altering R_id; if it is pinned, a separate E_id is linked to R_id.

Candidate set: The exact identities of all candidates considered.
Search scope and bounds: The sources, namespaces, depth, budgets, and the point of stopping.
Selected versions: The exact versions and digests of the selected artifacts and relations.
Rejected alternatives: The exact identities and machine-readable reason codes.
Conflicts and resolutions: The conflicts detected, their cores, and the resolutions applied.
Precedence: The precedence and tie-break rules used by Select.
Compatibility: The compatibility predicates checked and the validator versions.
Policies: The exact Policy identities applied to the selection.
Uncertainty: Structured residual uncertainty inside the ResolutionCore.
Search-Incomplete: A separate marker that the search bounds were exhausted; its absence cannot be inferred from the presence of a result.
Narrative Explanation: A human-readable explanation without hidden chain-of-thought; it lies outside R_id.

The canonical encoding of the ResolutionCore, the vocabulary of reason codes, the privacy profile, and the admissibility of residual uncertainty remain open. A stable digest pins a decision but does not prove it correct; the Explanation must not mask a divergence in the core.

Knowledge Contract

For a task q and a snapshot G_r, the semantic Contract and its issuance have distinct canonical records:

On a narrow screen the formula scrolls horizontally.

K_sem = canon(q_id, G_r[SemanticCut(q,r)], obligations, exclusions, R_id, schema_version) K_id = H(bytes(K_sem))

On a narrow screen the formula scrolls horizontally.

I = canon(K_id, issuer, authority_evidence, timestamp, signature, issuance_schema_version) I_id = H(bytes(I))

The internal structure of a Knowledge Contract: task, selected artifacts, constraints, success criteria, metadata, and the links to the BKG and the runtime. — **Figure 4.** An architectural diagram of the Knowledge Contract as a task-specific semantic cut. The arrows to the graph denote resolution and traceability; an issued contract does not modify the BKG.

SemanticCut(q,r) holds the exact node identities and digests, the required edges, unresolved declarations, exclusions, and the success criteria. The Contract references the immutable identifier of the Resolution Receipt: a Knowledge Contract pins the exact R_id but does not copy the Receipt. I references only a completed K_id; I_id is not among its own canonical inputs, so there is no recursive identity.

Task-specific: one task and one identity.
Immutable/content-addressed: a correction creates a new digest.
Exactly versioned: exact versions of objects and relations only.
Inspectable/replayable: the cut, the exclusions, R_id, and the semantic canonicalization profile are verifiable independently of I/I_id.
Provenance-aware: commitments are linked to evidence by immutable records.

Issue metadata is not part of K_id: a different issuer, timestamp, authority evidence, or signature creates a new I_id without altering the same K_sem/K_id. New commitments change K_id; re-issuing the same bytes changes only the issuance domain. A Contract is not a prompt, a repository, a Binding Record, a credential, or an authorization.

An interoperable profile must still choose a canonical serialization, a hash, the artifact schema, the BKG snapshot identity, ordering, time, and the handling of external evidence.

Gap Detection and Expansion

A Gap Record captures the required type or relation, the origin, the scopes searched, the bounds, the Evidence Profile, the risk class, the kind, and the terminal status. GapKind is a closed classification of the record, not a new managed artifact:

Semantic: The required artifact or relation does not exist.
Evidence: A candidate exists, but the Evidence Profile is not satisfied.
Version: No compatible approved version exists within the bounds.
Policy: A required applicable Policy is absent or ambiguous; a known conflict remains Policy-Conflict.
BindingProvider: A BindingGap is an operational diagnostic of Bind with the outcome Unbound and does not trigger Knowledge Expansion automatically.

Insufficient authority is an authorization failure, not a Gap: Issue-Unauthorized or Unauthorized applies. A scope mismatch likewise retains a terminal outcome of its own.

Gap Detection: completeness checking, detection of missing knowledge, proposal of a new artifact, and re-verification. — **Figure 8.** The architectural workflow of Gap Detection with mandatory validation: a candidate receives no immediate trust, and a local Expansion is not an Evolution of the repository.

Scope of an ExpansionArtifact

An ExpansionArtifact receives exactly one scope from a closed canonical set:

task-local: Available only to a re-resolution of the same task identity.
lineage-local: Available to the declared chain of derived tasks.
namespace-local: Available only within the specified governed namespace.
globally-reusable: A requested global scope; eligibility arises only after Evolution/promotion.

session-local requires explicit justification and is admissible only as a shorter-retention modification of task-local; it does not constitute a fifth promotion scope. Until the governance transition, an object is eligible only within its effective scope. A bounded publication does not make an object globally-reusable and does not add it to the globally reusable BKG.

The Expansion sequence

Gap Detection. A Gap Record captures the missing requirement, the search performed, and the bounds.
Synthesis/Acquisition. The system obtains a candidate, preserves its provenance, and declares the ExpansionArtifact scope.
Quarantine. The new object is not available to the Resolver as an accepted artifact and does not inherit the producer's trust.
Evidence. The evidence, tests, scenarios, and reviews required by the profile are collected.
Verification. Independent checks confirm the content, the evidence, and conformance to the scope.
Governance Review. An authorized party decides whether publication in the given scope is admissible.
Versioned Publication. An accepted object receives an immutable identity and a bounded visibility scope.
Resolver Eligibility. The profile permits re-selection only within the effective scope.

Promotion beyond a scope requires governed Evolution. A synthesized Skill or Policy passes through quarantine, and the producer cannot be the sole verifier, reviewer, and publisher of a risk-sensitive artifact.

Evidence Profiles

An Evidence Profile is specified by the pair artifact type × risk class and may require provenance, independent verifiers, tests, scenarios, security/Policy/human/domain review, compatibility, and replay. The inputs, the independence, and the thresholds are versioned; there is no universal confidence number.

An Expansion permits the closure to be retried, but may terminate in Reject, Ambiguous, or Search-Incomplete; a local cache is not an Evolution.

The Meaning Management lifecycle with the main assembly path and the separate Knowledge Expansion and Knowledge Evolution branches. — **Figure 9.** The architectural workflow separates Expansion, which closes a gap in the current resolution, from Evolution, which changes reusable knowledge only through a newly accepted versioned artifact.

An agent's self-correction is retained as an observation or proposal, but without independent verification it does not modify the shared Skill.

Controlled Evolution

Evolution publishes a successor with a new digest, provenance, and supersedes, without editing the prior version:

Execution Evidence. Observations are linked to the exact contract, binding, environment, and outcome.
Deficiency. A checkable defect of an existing artifact or profile is stated.
Root Cause. A cause residing in reusable knowledge is separated from a failure of search, binding, environment, or authorization.
Versioned Proposal. A successor candidate is created with a new digest and a semantic diff.
Validation/Regression. The profile's checks are run, including the impact on dependent Blueprints and on historical fixtures.
Governance Approval. An authorized publisher accepts or rejects the new version; the producer does not approve it unilaterally.
Versioned Publication. The approved immutable version is published alongside its predecessors.
BKG Update. A new graph snapshot adds the successor and the applicability statuses without deleting history.
Resolver Adoption. Only future resolutions may select the new version, under the rule latest compatible approved version.

A historical Contract remains pinned; the successor is available only in a new BKG snapshot. Deprecation, supersession, and revocation do not delete history; the current Auth may forbid repeating the action.

Expansion ≠ Evolution. The former closes a task gap; the latter admits reusable knowledge after independent assessment, tests, and an authority decision. Frequency or a model score does not substitute for that transition. The deployment profile separately specifies the retention of snapshots, receipts, blobs, hashes, and removed sources.

Governance and Authority

A governance loop around the Knowledge Contract: policy engine, planner, runtime, observability, validation, and evolution. — **Figure 10.** An architectural diagram of the governance loop around the Knowledge Contract. Authorizing a particular action and accepting a new version remain separate decisions of authority.

Open question. The authority model is not complete. It must distinguish the producer, the verifier, the publisher, the contract issuer, the binding approver, the runtime action authority, and human authority. A Role is not an authority; a risk-sensitive profile justifies segregation of duties and governance independence.

AuthorityCut(t) is the snapshot of authorities for a principal/action/resource; PolicyCut(t) is the snapshot of the rules in force. A future model must specify a versioned AuthorityGrant, delegation, scope, expiry, the human chain, revocation, emergency override, conflicts, and an independence proof. This is an external governance interface, not a Variant A type and not a complete IAM model.

Cedar and OPA can compute a policy decision [18] [17]; the Contract supplies them with identities but does not replace them. A CapabilityDescription, a Binding Record, and a Role do not confer the right to act. Insufficient authority is an admissible terminal outcome, not a reason to force Issue or execution.

Runtime Binding and the Authorization Boundary

Contrasting cases of binding and authorization for a single example are given in Appendix C.

Execution architecture: Knowledge Contract, agent runtime, tools and services, observability, validation, and the result. — **Figure 12.** An architectural runtime diagram of execution. The Binding proves a concrete realization of the commitments, while a separate authority-at-time-t check decides whether the action may be performed.

A CapabilityDescription is normalized into a CapabilityType; Bind searches for an adapter by inputs, outputs, effects, and trust properties. A function, a CLI, an API, or an agent protocol may realize one type, but the transport does not prove equivalence or authority. OWL-S likewise distinguishes the profile, the process model, and the grounding [21].

A Binding Record holds K_id, the obligation, the CapabilityType, the adapter and version, the interface digest, the transport, the environment, the equivalence evidence, the verifier, the validity, and the digest. Secrets are replaced by a safe reference; changing the adapter, interface, or environment requires a rebind.

Authorization is stated separately:

On a narrow screen the formula scrolls horizontally.

Auth(principal, action, resource, t | AuthorityCut(t), PolicyCut(t)) -> Allow | Deny(reason) | Indeterminate(reason)

On a narrow screen the formula scrolls horizontally.

Executable(K,B,a,t) = ContractPermits(K,a) AND BindingValid(B,K,a) AND Auth(principal,action,resource,t | AuthorityCut(t),PolicyCut(t)) = Allow

The action is not part of the Contract: ContractPermits merely checks it against the obligations and prohibitions. BindingValid = false forbids execution; Deny or Indeterminate forbid the action. The unavailability of Auth is never converted into Allow.

Decision = canon(K_id, B_id, I_id?, AuthorityCut_id, PolicyCut_id, principal, action, resource, timestamp, outcome, reason). I_id is included when the profile requires proof of a particular issuance; the absence of that field does not join the semantic and issuance identities.

Provenance, Evidence, and Versioning

PROV-O defines Entity, Activity, and Agent [12]. A task-specific transition record adds input/output identities, the operation and version, the actor or service, time, the decision and reasons, evidence, policy and authority identities, and the failure class.

On a narrow screen the table scrolls horizontally.

Transition	What is recorded	What cannot be inferred after the fact
Propose	Source locator, producer, retrieval parameters, raw digest, declared type.	That the source was accepted or true.
Verify	Schema/evidence/authority checks, validator versions, verdict.	That every possible source was found.
Select	Candidates, hard constraints, precedence, rejected alternatives, conflict core.	That the ranking was the only one possible.
Resolution Receipt	The ResolutionCore: candidate identities, bounds, selection, reason codes, conflicts, precedence, uncertainty, Policy identities, and Search-Incomplete; the Explanation and `E_id` separately.	That the narrative is part of `R_id` or proves the selection correct.
Assemble/Issue	`K_sem/K_id`, then the separate issuer, authority evidence, time, signature, and `I/I_id`.	That issue metadata is part of `K_id`, or that the contract is executable after the environment has changed.
Bind	`K_id`, the adapter/interface/environment identity, equivalence evidence, validity, and `B_id`.	That the invocation is permitted.
Authorize	`K_id/B_id`, where required `I_id`, the action, the principal and resource, the cut identities, the timestamp, the outcome, and the reason.	That the action is part of the Contract, or that it will be permitted later.

Provenance does not prove relevance or authority. The ResolutionCore holds the verifiable fields of the selection; the Explanation serves the human reader; the issuance and execution records separately capture authority and the decision in time.

The digest is the definitive content identity; a semantic version merely helps the human reader. A mutable "current" is admissible in search, but a Contract holds an exact version and does not alter a prior K_id.

Levels of Reproducibility

The word "reproducibility" without a level creates a false promise. The architecture distinguishes three scientific levels; the reproducibility of the publication package build is verified separately and does not substitute for any of them.

Semantic reproducibility. Given frozen candidates, a BKG snapshot, profiles, bounds, and canonical rules, SemanticCut, ResolutionCore/R_id, and K_sem/K_id are compared. This is a derived property of the fixed inputs, not proof that the selected meaning is correct.
Decision reproducibility. Given frozen issue inputs, I/I_id is compared separately, and for a runtime decision so are K_id, B_id, the identities of AuthorityCut(t)/PolicyCut(t), the timestamp, the outcome, and the reason. One Contract may have different legitimate issuances; HYP-003 tests for the absence of cross-domain identity drift, but has not been executed.
Operational reproducibility. Given the same K_id, B_id, environment, and runtime cuts, the system attempts to repeat the trace and the domain outcome, or else to explain the divergence. Time, external services, and removed providers may preclude byte-identical replay or independent replication of the result.

Observation about the package. A frozen tree and toolchain yield a verifiable build; reproducibility requires the inputs, the environment, the instructions, and a comparison [19]. The private corpus holds 63 raw images; the public atlas holds 62 hashed versions. Only the build and the boundary are demonstrated — not Resolver replay, not the correctness of a decision, and not the usefulness of the Contract.

End-to-End Architecture

Available context becomes candidates in Propose; Verify checks identity, type, evidence, validity, and scope; Select produces the compatible cut and the ResolutionCore; Assemble canonicalizes K_sem/K_id and, where the authority exists, creates I/I_id. The runtime adapter has not yet been selected.

Post-issuance Bind instructs the runtime/harness to create a Binding Record. Before an action, the authorization interface evaluates the principal, action, and resource against AuthorityCut(t)/PolicyCut(t); traces and outcomes may initiate a Gap or an Evolution Proposal, but do not alter the Contract.

Model + Harness + Meaning Management denotes responsibilities, not identities: the Model proposes, the Harness executes and observes, and Meaning Management fixes the commitments. MCP, a CLI, A2A, an API, databases, and adapters belong to the runtime/harness. The core specifies types, relations, invariants, closure, compatibility, provenance, versioning, and validation, but not the graph, database, transport, framework, provider, or orchestrator.

V. Evaluation and Falsification

The Experimental Programme

The full unified specification of HYP-001–009 and EXP-001–009 is given in Appendix D.

Untested expectation. What follows is a preregistration draft. The datasets are not frozen, no power analysis has been performed, and no experiment has been run. Expected directions are not results.

Datasets and Fixtures

D1 — Canonical task fixtures: Tasks from the original Research 17 corpus with manually fixed required artifacts, relations, and admissible terminal states.
D2 — Adversarial semantic fixtures: Omissions, conflicting versions, malicious Policy, misleading retrieval, an underspecified SuccessCriterion, and plausible synthesized gaps.
D3 — Evolution histories: Chains of successors, revocations, delayed evidence, and historical replay points.
D4 — Transport and binding fixtures: Semantically equivalent and non-equivalent CLI, API, MCP, and A2A adapters with controlled differences in effects.
D5 — Double-annotation corpus: Independent expert annotation of Role, Skill, Blueprint, and the four operational/governance types.
D6 — External Naturalistic Task Corpus: A future corpus independent of the Variant A construction, with natural ambiguity, missing knowledge, Policy conflicts, and tool bindings. As of the semantic/preregistration freeze, corpus D6 has not been collected; no results exist.

A dataset version requires a digest, a data statement, inclusion/exclusion rules, labels, an adjudication log, and a frozen split. D1–D4 test synthetic mechanics; D5 requires qualified annotators and the resolution of disagreements. D6 remains to be collected and preregistered independently.

Comparable Baselines

B0 — Prompt-only: Context without typed artifacts or receipts.
B1 — Retrieval + planner: RAG and a planner without a contract cut.
B2 — Flat manifest: Exact versions without BKG closure, typed failures, or a separate Auth.
B3 — Workflow + policy engine: Workflow and policy-as-code without provenance-aware semantic selection.
B4 — Full proposed profile: The complete Meaning Management v1 construction.

Task inputs, the candidate universe, budgets, and adapters are identical. Additional retrieval calls or annotation are counted as treatment cost; failures and abstentions remain in the denominator.

A Limited Set of B4 Ablations

Four single ablations are fixed before the run; the set is not a full factorial design. The remaining B4 components, the inputs, and the budgets are preserved.

On a narrow screen the table scrolls horizontally.

Ablation	What it isolates	Interpretation
B4 without the Resolution Receipt	The contribution of decision provenance and diagnosability.	Do replay of the selection, recovery of reasons, and diagnostics change while the Contract and the remaining checks are preserved?
B4 without bounded BKG closure	The contribution of structured bounded semantic resolution.	Do completeness, conflict detection, Search-Incomplete, and cost change under the same candidate universe?
B4 without separate Authorization	The contribution of separating semantic permission from runtime authority.	Do policy violations and false allow/deny change if Auth_t is not separated from the Contract and the Binding?
B4 without Evidence Profiles	The contribution of risk/type-dependent admission governance.	Do false acceptance, abstention, and human-review cost change without profile-specific evidence requirements?

Variables and Metrics

Independent variables: architecture condition B0–B4, task family, risk class, candidate noise, conflict density, graph depth, evolution distance, transport, and authority change. Control variables: model/version, decoding, tool versions, time/retrieval budget, the initial BKG snapshot, and the random seed where one applies.

On a narrow screen the table scrolls horizontally.

Metric	Definition	Unit	Aggregation	Direction	Constraint
Resolution/context overhead	Additional latency, model tokens, memory, graph operations, and human-review time relative to a comparable baseline.	ms, tokens, bytes, graph operations, person-minutes	Median, tail quantiles, and the stratified paired difference by task/risk class.	Lower, while the error/replay gain is preserved.	The task budget and candidate universe must be identical; first resolution and replay are counted separately.
Critical-error gain	The change in the rate of critical semantic, policy, and binding errors relative to the baseline.	percentage points and relative risk	By risk class, with failures and abstentions in the denominator.	A larger positive reduction in errors.	Severity weighting and the practically meaningful minimum must be frozen before the main outcomes.
Replay gain	The change in the proportion of repetitions with the same terminal state and, separately, the same R_id, K_id, and I_id under frozen inputs of the corresponding domain.	proportion and percentage-point difference	By identity domain and by class of admissible divergence.	Higher under unchanged frozen inputs.	Narrative drift does not change R_id; issue metadata drift must not change K_id.
Search-Incomplete rate	The proportion of tasks that ended in an explicit Search-Incomplete under the declared bounds.	proportion	By bounds, risk class, and graph depth.	Lower, without hidden coercion into Closed.	A zero proportion may indicate a defect of observability rather than completeness.
Assembly failure rate	The proportion of selected cuts not issued because of canonicalization, Receipt, schema, or Issue authority failure.	proportion by failure class	Technical assembly and Issue-Unauthorized separately.	Lower, while fail-closed semantics is preserved.	Issue-Unauthorized must not be counted as a serialization error or removed from the denominator.
Inter-annotator agreement	Agreement among independent experts on the seven types, relation types, conflicts, and terminal states.	Cohen’s kappa or Krippendorff’s alpha and a confusion matrix	The coefficient and a confidence interval under a profile chosen in advance.	Higher, with no systematic conflations.	The metric and the lower bound are chosen before the run; class imbalance is analysed separately.
Compatibility accuracy	Precision/recall of the compatibility of semantic cuts and bindings against adjudicated fixtures.	precision, recall, false-accept rate	By relation type, adapter effects, and risk class.	Higher precision/recall and fewer false accepts.	A matching interface name or transport does not prove semantic compatibility.
Governance false-positive rate	The proportion of admissible publications, issuances, bindings, or actions wrongly rejected by the governance profile.	proportion	By decision surface and risk class.	Lower, without trivially permitting everything.	A governance reject must be distinguished from a technical failure, and human-review cost must be counted.
Governance false-negative rate	The proportion of inadmissible publications, issuances, bindings, or actions wrongly permitted by the governance profile.	proportion with severity weighting	By decision surface, risk class, and consequence class.	Lower.	A mean proportion without severity may conceal rare critical errors.

Thresholds for Preregistration

The numeric thresholds below are deliberately not chosen. They are to be fixed before the first main run on the basis of pilot data, power analysis, the cost of errors, and risk appetite. Once the main outcomes have been inspected, a threshold may not be changed without registering a new hypothesis.

On a narrow screen the table scrolls horizontally.

Quantity	Threshold status	What must be frozen before the run
Resolution/context overhead	TBD before preregistration	The task budget and candidate universe must be identical; first resolution and replay are counted separately.
Critical-error gain	TBD before preregistration	Severity weighting and the practically meaningful minimum must be frozen before the main outcomes.
Replay gain	TBD before preregistration	Narrative drift does not change R_id; issue metadata drift must not change K_id.
Search-Incomplete rate	TBD before preregistration	A zero proportion may indicate a defect of observability rather than completeness.
Assembly failure rate	TBD before preregistration	Issue-Unauthorized must not be counted as a serialization error or removed from the denominator.
Inter-annotator agreement	TBD before preregistration	The metric and the lower bound are chosen before the run; class imbalance is analysed separately.
Compatibility accuracy	TBD before preregistration	A matching interface name or transport does not prove semantic compatibility.
Governance false-positive rate	TBD before preregistration	A governance reject must be distinguished from a technical failure, and human-review cost must be counted.
Governance false-negative rate	TBD before preregistration	A mean proportion without severity may conceal rare critical errors.

Falsifiable Hypotheses

The matrix links nine hypotheses to nine separate protocols. The numeric bounds remain TBD pending a pilot, power analysis, and preregistration; HYP-004 and HYP-006 are tested as deterministic properties.

On a narrow screen the table scrolls horizontally.

Hypothesis / protocol	Research question	Expected direction	Falsification condition
HYP-001 · EXP-001 Completeness	Does B4 improve the completeness of the correct semantic cut relative to retrieval/flat-manifest baselines?	Higher precision/recall without an increase in conflicting inclusions.	The preregistered margin/gain is not reached, or the effect disappears on the holdout.
HYP-002 · EXP-002 Policy safety	Does separating the Contract, the Binding, and Auth_t reduce the number of hard-policy violations?	Fewer violations and governance false negatives.	There is no preregistered reduction, or privilege amplification appears.
HYP-003 · EXP-003 Replay	Do separate ResolutionCore, Contract, and issuance identities improve the reproducibility of decisions?	Higher replay of each frozen identity domain without cross-domain drift.	Issue metadata changes K_id, the narrative changes R_id, or a frozen domain is not reproduced.
HYP-004 · EXP-004 Revocation without history rewrite	Are historical bytes preserved when the current authority changes?	Historical identity stable; revoked action is not allowed.	Any change of historical bytes, or Allow after an effective revocation.
HYP-005 · EXP-005 Conflict diagnostics	Does typed Select plus the Receipt improve reproducible diagnostics of conflicts and gaps?	Higher reconstruction adequacy and gap precision/recall.	The conflict is not reconstructed, or the diagnostics do not surpass the baseline.
HYP-006 · EXP-006 Bounded recursion	Does BKG traversal terminate within the bounds with an honest terminal state?	Termination within B and explicit Search-Incomplete when closure is not established.	Timeout/overrun, hidden incompleteness, or a forced Closed.
HYP-007 · EXP-007 Transport equivalence	Does a semantic BindingCut improve the recognition of equivalent and non-equivalent providers?	Higher compatibility precision/recall and fewer false accepts.	An incompatible adapter is accepted, or the effects diverge.
HYP-008 · EXP-008 Cost	Is the overhead of B4 justified by the observed error/replay gain?	Not specified; acceptability depends on the preregistered risk-class trade-off.	The overhead exceeds the gain, or B2/B3 is equivalent at a lower cost.
HYP-009 · EXP-009 Ontology agreement	Do the Variant A rules improve inter-expert agreement on the types and the forbidden merges?	Higher agreement and fewer systematic conflations.	Low agreement, or a persistent conflation of types.

Analysis and Reporting

Before the run, the primary/secondary outcomes, margins, sample size, stopping rules, and exclusion policy must be frozen. For rates, the effect size and a confidence interval should be published, not the p-value alone. For every seed and failed run, the inputs, terminal state, receipts, and logs are retained, with secrets safely redacted. The analysis script, the schemas, the container/toolchain identities, and the raw denominators form part of the replication package.

The qualitative rejection conditions apply regardless of which numbers are chosen later.

There is no material reduction of critical semantic, policy, or binding errors.
The resolution/context overhead is excessive relative to the errors prevented.
Independent annotators do not reach stable agreement.
Search-Incomplete persists systematically on naturalistic tasks under reasonable bounds.
Frozen inputs do not reproduce the terminal state and the corresponding R_id/K_id/I_id.
The cost and errors of governance exceed the observed gains.
B2 or B3 provides equivalent guarantees at a substantially lower cost.

Any of these outcomes requires simplifying or rejecting the corresponding part of B4, rather than changing the metric after the analysis. The absence of numbers chosen in advance in the present paper is a limitation of the preregistration draft, not a licence to interpret any outcome as a success.

VI. Discussion and Limitations

Discussion

What the architecture formally specifies: The distinctions between available context and selected commitment, semantic Contract and issuance, Contract, Binding and Auth, and Expansion and Evolution; the identity and lifecycle of the records; the admissible terminal states and the historical pinning of exact versions.
What remains a hypothesis: A reduction in critical errors, improved replay and diagnostics, acceptable cost, natural generalizability, and an advantage of B4 over the baselines.
What is deliberately out of scope: Human-like meaning, an AGI control plane, full operational replay of the open world, and the choice of particular storage, graph, policy, transport, framework, or model technologies.
What may be simplified: The Receipt, bounded closure, separate authorization, or Evidence Profiles are to be reduced or removed if the preregistered ablations do not show a contribution of their own, or if the cost exceeds the measurable gain.

Meaning Management moves hidden prompt integration into types, relations, receipts, versions, and terminal states. This is useful only where errors are detected earlier or explained better; records without a reduction in material violations are an administrative burden. The weight of the profile depends on risk: a read-only task with a stable Skill admits a small Contract and binding, whereas external effects and several principals require detailed receipts and segregation of duties.

A retrieval error belongs to Propose; a semantic, evidence, version, or policy deficit to GapKind; a scope mismatch to Verify/Select; issuer authority to Assemble; a BindingGap to Bind/Unbound; and revocation to Auth. An authority failure is not a Gap. The price of this distinguishability is the combinatorial BKG and the governance surface; poor agreement rejects the more complex ontology.

On a narrow screen the table scrolls horizontally.

Type of claim	Current status
Architectural decomposition	Proposed and formally specified.
The identity model	Formally specified.
The resolution lifecycle	Formally specified.
Historical semantic replay	A derived property under frozen inputs.
A reduction in critical errors	Hypothesis.
Improved diagnostics	Hypothesis.
Acceptable cost	Hypothesis.
Generalization to naturalistic tasks	An open empirical question.

Limitations

There is no implementation and there are no outcomes. The API, schemas, solver, nine hypotheses, and nine protocols have not been executed; D6 has not been collected.
The solver properties are not proved. Soundness, completeness, and complexity remain open; bounded search admits Search-Incomplete.
The review is purposive. The corpus may miss a closely related or a recent system.
The ontology and governance are incomplete. Independent annotation, risk-specific authority, thresholds, and retention are required.
The open world limits inference. A provider that was not found may exist; receipts do not guarantee replication of the outcome.
The graphics are heterogeneous. The private corpus holds 63 raw images; the Main text has 13 diagrams, the register 14, and the public atlas 62. The text is normative.

The open world. Search-Incomplete is an admissible outcome; the absence of a found object does not prove that it does not exist, and the architecture does not guarantee completeness of search in an open world.

Future Research

The programme includes executable serialization, schemas, hashes, and fixtures; an independent naturalistic D6; a comparison of a purpose-built BKG with RDF/SHACL; authority profiles; semantic binding; the composition of Contracts; privacy-preserving receipts; and a comparison of memory/RAG with BKG resolution. Poincaré embeddings, MCP, a CLI, and A2A remain options for indexing, binding, and transport.

Higher-Order Compositions of Semantic Artifacts

A non-normative direction for future research. Variant A is not extended. Competency is a higher-order domain concept representing a claimed or verifiable ability of a subject to perform a particular class of professional work in a given context and to the required standard of quality. A verified competency claim requires separately defined Competency Evidence. A Competency may compose Roles, Skills, Blueprints, Constraints, Policies, SuccessCriteria, CapabilityDescriptions, and evidence requirements. Profession is a stable broad class of professional activity, not a Role and not merely reusable context.

On a narrow screen the table scrolls horizontally.

Concept	The principal question	The boundary in this version
Profession	To which stable broad class of professional activity does the work belong?	A future external layer; Profession ≠ Role.
Role	What responsibility and decision scope are assumed in this context?	A managed Variant A artifact; not a profession and not authority.
Competency	Is the subject able to perform a particular class of professional work in a given context and to the required standard?	A future evidence-aware composition; Skill ≠ Competency.
Skill	How is a particular operation or class of operations performed?	A managed Variant A artifact; the presence of a reference does not prove Competency.
Capability	Can the runtime realize the required operation?	A CapabilityType is derived from a CapabilityDescription; Capability ≠ Competency.
Blueprint	Which managed pattern guides the work?	A managed Variant A artifact, not a profession or a profile of a subject.
Agent/Worker	Who or what performs the work?	Not a semantic artifact, a Role, a Profession, a Competency, or a Contract.
Knowledge Contract	Which semantic commitments govern this task execution?	A task-specific executable specification, not a CV, a profile, or a passport.

A compact example. The Profession Lawyer; the Competency Commercial Contract Review; the Role Contract Reviewer; the Skills Clause Extraction, Legal Interpretation, and Risk Classification; the Blueprint Commercial Contract Review; the Policy is determined by the jurisdiction; the SuccessCriteria measure coverage and risk detection; the Evidence consists of validated review results. A reference to a Skill does not prove Competency: Artifact Evidence confirms an artifact, while Competency Evidence confirms the claimed composition and level.

An AgentProfile/WorkerProfile and a CompetencyProfile remain possible external profiles. The relations form a typed many-to-many graph, not a strict hierarchy. The Knowledge Contract remains a task-specific executable semantic specification and is not a CV, a profile, or a passport.

No matching model has been chosen among "the exact profession", "a composition of competencies", and "a direct task cut"; they are to be compared empirically. A Profession Repository is not part of v1: a possible professional knowledge base is a separate upper layer and a potential field of application, not a marketplace, a pricing model, or a new core of the architecture.

Semantics.: How should a representation for Competency be chosen; how should proficiency and domain be specified; how should recency, decay, and revalidation be accounted for?
Evidence and subjects.: How should Artifact Evidence, which confirms a managed artifact, be separated from Competency Evidence for a verified competency claim about a human, an AI system, or a hybrid subject?
Professional composition and matching.: How do a Profession, a CompetencyProfile, a WorkerProfile, and the BKG participate in composition, and at exactly which point should matching be performed relative to the Resolver and the issuance of the Knowledge Contract?

Open Research Questions

Authority: how should AuthorityCut(t), PolicyCut(t), an AuthorityGrant, delegation, revocation, human authority, and segregation be connected without covertly moving IAM inside the Contract?
Evidence: which checks are sufficient for each type × risk pair?
Receipt: how should identity, uncertainty, Search-Incomplete, and privacy be canonicalized?
Falsification: which gains, overhead/error limits, sample size, and stopping rules should be preregistered?
Governance independence: what prevents producer self-approval and conflict of interest?
CapabilityType: when would independent ownership, governance, versioning, and lifecycle justify promotion?
Composition/disclosure: how should cross-contract conflicts and digests/Policy be checked without disclosing secrets, personal data, or hidden reasoning?

VII. Conclusion

The conceptual result obtained. The proposed model separates available context from the selected semantic commitment; it fixes the selection through a Resolution Receipt; it separates the Knowledge Contract from issuance; and it separates the semantic Contract from the Binding, and the Binding from runtime Authorization. Reusable artifacts acquire identity, versioning, governance, and provenance; Expansion is separated from Evolution; and historical semantic commitments may be pinned and replayed where the preconditions have been preserved.

The empirical result not obtained. A reduction in critical execution errors, improved replayability and diagnosability, the acceptability of the overhead, and the superiority of B4 over the baselines have not yet been established. The nine protocols remain a preregistration specification without outcomes.

The practical value of this decomposition must be tested experimentally; absent a measurable gain, the corresponding mechanisms are to be simplified or rejected. The principal scientific result of this work is the path from available knowledge to a selected semantic commitment, from the commitment to a concrete realization, and from the realization to a permitted action — made explicit, versioned, explainable, and auditable, and presented as a formally specified object of research rather than as an empirically confirmed superiority.

References

The corpus is limited to directly relevant scientific works and official specifications verified in this cycle; the links lead to the authors, the publishers, or the standards bodies.

Prompt engineering · class: Direct. P. Liu, W. Yuan, J. Fu, Z. Jiang, H. Hayashi, G. Neubig. Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing. ACM Computing Surveys 55(9), 2023. DOI 10.1145/3560815. Scientific work or official specification. Used here: Systematizes prompt-based learning and the ways a task may be specified by a text template; it does not specify a governed versioned semantic cut.
In-context learning · class: Direct. T. Brown et al. Language Models are Few-Shot Learners. Advances in Neural Information Processing Systems 33, 2020. Scientific work or official specification. Used here: Demonstrations and instructions are supplied in the inference context without changing the parameters; acceptance, version, and authority do not become separate objects.
In-context learning · class: Direct. S. Min et al. Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? EMNLP 2022, pp. 11048–11064. DOI 10.18653/v1/2022.emnlp-main.759. Scientific work or official specification. Used here: Shows that the format, the input distribution, and the label space may matter more than the correctness of the labels; this underscores the risk of equating available context with accepted meaning.
Retrieval-augmented generation · class: Direct. P. Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33, 2020. Scientific work or official specification. Used here: Combines parametric and non-parametric memory with retrieved passages; the relevance of a retrieval is not a governance acceptance of a commitment.
Agent planning and action · class: Direct. S. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. Scientific work or official specification. Used here: Interleaves reasoning traces with actions in an external environment; it does not issue an independent immutable contract with a versioned authority boundary.
Multi-agent systems · class: Direct. G. Li, H. A. K. Hammoud, H. Itani, D. Khizbullin, B. Ghanem. CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. NeurIPS 2023. Scientific work or official specification. Used here: Role-playing and communicative cooperation shape the behaviour of the agents; the roles remain a prompt-level mechanism rather than an independently governed artifact graph.
Multi-agent orchestration · class: Direct. Q. Wu et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversations. Conference on Language Modeling, 2024. Scientific work or official specification. Used here: Conversable agents, roles, capabilities, tools, and conversation programming; it does not define a common resolver lifecycle or a historically pinned semantic cut.
Agent memory · class: Direct. J. S. Park et al. Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. DOI 10.1145/3586183.3606763. Scientific work or official specification. Used here: Observation, memory retrieval, reflection, and planning sustain long-running behaviour; memory is not equivalent to an approved set of task obligations.
Agent memory · class: Direct. C. Packer et al. MemGPT: Towards LLMs as Operating Systems. arXiv:2310.08560, v2, 2024. Scientific work or official specification. Used here: Virtual context management moves material between memory tiers; the availability of the material does not settle its evidence, compatibility, or authority status.
Knowledge graphs and ontologies · class: Direct. A. Hogan et al. Knowledge Graphs. ACM Computing Surveys 54(4), Article 71, 2021. DOI 10.1145/3447772. Scientific work or official specification. Used here: Surveys graph data models, schema, identity, context, deduction, quality, and evolution; the BKG profile adds task-specific resolution and contract issuance.
Knowledge graphs and ontologies · class: Supporting. W3C. Shapes Constraint Language (SHACL). W3C Recommendation, 20 July 2017. Scientific work or official specification. Used here: Defines shapes and validation reports for RDF graphs; it is suitable for part of Verify, but it does not select the task cut and does not issue a contract.
Provenance · class: Supporting. T. Lebo, S. Sahoo, D. McGuinness, eds. PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013. Scientific work or official specification. Used here: Represents Entities, Activities, Agents, and provenance relations; the candidate set, the bounds, the alternatives, Search-Incomplete, and the immutable Resolution Receipt remain an application profile of this architecture.
Workflow languages · class: Direct. P. Amstutz et al. Methods Included: Standardizing Computational Reuse and Portability with the Common Workflow Language. Communications of the ACM 65(6), 2022. Scientific work or official specification. Used here: CWL describes portable command-line tools and directed workflows; semantic commitments and the authority required before execution lie outside its principal object.
Workflow languages · class: Supporting. Object Management Group. Business Process Model and Notation (BPMN), version 2.0.2. Formal specification, 2014. Scientific work or official specification. Used here: Standardizes processes, collaborations, and choreographies; it does not resolve heterogeneous knowledge into an immutable task contract.
Software architecture · class: Supporting. ISO/IEC/IEEE 42010:2022. Software, systems and enterprise — Architecture description. Second edition, 2022. Scientific work or official specification. Used here: Specifies requirements for architecture descriptions, viewpoints, and model kinds; a Blueprint in this work is a versioned reusable input to resolution, not an entire architecture description.
Software architecture · class: Direct. P. Clements et al. Documenting Software Architectures: Views and Beyond. Second edition. Addison-Wesley / Carnegie Mellon SEI, 2010. Scientific work or official specification. Used here: Links views, interfaces, behaviour, and rationale into a documentation package; it does not specify a runtime semantic resolver or action authorization.
Policy-as-code · class: Supporting. Open Policy Agent Project. Policy Language: Rego. Official language documentation. Scientific work or official specification. Used here: Declaratively evaluates rules over structured input/data; it is a possible mechanism for Verify/Auth, but it does not form the semantic cut, the Resolution Receipt, or the Knowledge Contract.
Policy-as-code · class: Supporting. Cedar Policy Project. Cedar Policy Language Reference Guide, version 4.5. Scientific work or official specification. Used here: A decision over principal, action, resource, and context directly supports the action-specific authorization boundary; AuthorityCut(t), semantic selection, and binding remain separate constructions.
Reproducible systems · class: Supporting. Reproducible Builds Project. Making plans for reproducible builds. Official project documentation. Scientific work or official specification. Used here: Fixes the source, the environment, the instructions, and a comparison protocol; the paper carries the discipline of exact inputs over to semantic assembly without equating a runtime outcome with byte identity.
Governance · class: Supporting. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, 2023. Scientific work or official specification. Used here: Describes govern/map/measure/manage for AI risk; it does not specify Evidence Profiles by artifact type × risk class, a versioned artifact calculus, or a Resolver.
Semantic service descriptions · class: Supporting. OWL Services Coalition. OWL-S: Semantic Markup for Web Services. W3C Member Submission, 2004. Scientific work or official specification. Used here: Distinguishes the service profile, the process model, and the grounding; this is a useful precursor of the separation of CapabilityDescription, abstract type, and concrete binding.
Knowledge graphs and ontologies · class: Supporting. R. Cyganiak, D. Wood, M. Lanthaler, eds. RDF 1.1 Concepts and Abstract Syntax. W3C Recommendation, 25 February 2014. Scientific work or official specification. Used here: Provides a graph model of triples and datasets; versions, authority, compatibility, and contract identity require an application profile on top of it.

Appendix A. Formal Specification of a Managed Artifact

Purpose. To specify the minimal properties that allow an object to be considered a managed semantic artifact in Meaning Management v1.

Scope. The normative core covers the seven Variant A types; concrete serialization, repository layout, and transport remain implementation options.

Relation to the main text. The appendix makes the terminology and the ontology of managed artifacts concrete and introduces no additional normative requirements on the architecture.

Normative content. The fields and distinctions below pertain to the v1 profile. Examples of concrete values are marked as illustrative and do not constitute a mandatory wire format.

A.1. Generic Managed Artifact

A managed artifact is a semantic object, not a means of storing it. Its normative core contains the following fields:

artifact_id
artifact_type
version
content_identity
schema_version
status
provenance
evidence_profile
compatibility
governance_status
created_at
supersedes
derived_from

On a narrow screen the table scrolls horizontally.

Class	Contents	Architectural status
Normative core fields	Identity, type, version, content identity, schema, lifecycle status, provenance, evidence, compatibility, governance, time, and lineage.	Mandatory in meaning; the concrete encoding is determined by the interoperability profile.
Implementation-specific metadata	Storage URI, database key, cache hint, index embedding, UI label, transport locator, and local retention marker.	They do not change the architecture and do not become part of the content identity without an explicit profile decision.

A.2. Artifact Identity

Logical artifact identity: The stable line of an object, for example role:api-maintainer, uniting compatible versions.
Artifact version: An immutable published revision of that line, for example @2.1.0. A successor coexists with its predecessor and is linked through supersedes.
Content identity: The digest of the canonical bytes of a particular version. A change of content creates a different digest regardless of the human-readable version.

A published version is immutable. The statuses deprecated, superseded, and, where the safety profile supports it, revoked change applicability, but they do not rewrite its prior bytes or historical Contract references. The full semantics of withdrawal remains open research if runtime safety requires a stronger distinction among these statuses.

A.3. Artifact Types

On a narrow screen the table scrolls horizontally.

Type	Variant A class
`Role`	A primary reusable semantic artifact
`Skill`	A primary reusable semantic artifact
`Blueprint`	A primary reusable semantic artifact
`Constraint`	An additional typed operational/governance artifact
`Policy`	An additional typed operational/governance artifact
`SuccessCriterion`	An additional typed operational/governance artifact
`CapabilityDescription`	An additional typed operational/governance artifact

CapabilityDescription is managed and versioned; CapabilityType is a derived representation obtained by normalization. The relation has a direction, CapabilityDescription → normalization/derivation → CapabilityType, and is not an equality. A possible future promotion requires independent ownership, governance, versioning, and lifecycle, and is not part of v1.

A.4–A.9. An End-to-End Illustrative Example

A constructed illustrative example. The task task:protected-endpoint-change:2026-08 requires changing a protected administrative endpoint without changing the public API contract, and verifying authorization, validation, negative scenarios, and audit evidence. This is not an empirical dataset and not a measured outcome.

On a narrow screen the table scrolls horizontally.

Type	Illustrative exact reference
`Role`	`role:api-maintainer@2.1.0`
`Skill`	`skill:modify-protected-endpoint@3.0.1`
`Blueprint`	`blueprint:protected-endpoint-authorization@4.2.0`
`Constraint`	`constraint:public-api-compatibility@1.4.0`
`Policy`	`policy:current-explicit-admin-authorization@5.0.0`
`SuccessCriterion`	`success:protected-endpoint-security-regression@2.0.0`
`CapabilityDescription`	`capability:source-code-modification-and-test@1.3.0`

A.4. Role

Responsibility: To preserve the architectural integrity of the protected endpoint and to deliver a verifiable change.
Decision scope: The choice of an admissible patch within the specified endpoint and the associated security tests; a change to the public API is excluded.
Ownership: The artifact line belongs to the governed namespace of architectural roles.
Governance boundaries: A Role does not publish a version of its own, does not issue credentials, and does not take a runtime authorization decision.
Compatibility: Compatible with Blueprint major 4 and Skill major 3 where the Evidence Profile has been satisfied.
Version and provenance: role:api-maintainer@2.1.0; the source, producer, verifier, and publication event are addressed separately.

Role ≠ Authority. The right of a principal to change the endpoint arises only through AuthorityCut(t), PolicyCut(t), and Auth_t in Appendix C.

A.5. Skill

skill:modify-protected-endpoint@3.0.1 specifies a reusable procedure: accept the task diff and the frozen contract references; check the preconditions; prepare a minimal change; run validation and negative tests; return the patch, the test evidence, and the failure class. The required abstract capabilities are reading and modifying source code, running scoped tests, and forming audit evidence. A CLI, an MCP server, an API client, and a vendor SDK are absent from the Skill and are chosen later by Binding.

A.6. Blueprint

blueprint:protected-endpoint-authorization@4.2.0 describes a framework-neutral architectural pattern: authentication before the protected operation; explicit permission enforcement; an authorization guard; fail-closed denial; a validation boundary; an audit event; and positive and negative test cases. The dependencies point to the Role, Skill, Policy, Constraint, SuccessCriterion, and CapabilityDescription by exact version constraints. A Blueprint does not declare a concrete middleware library and is not an authority grant.

A.7. Policy / Constraint Contrast

On a narrow screen the table scrolls horizontally.

Object	Illustrative content	Function
Policy	Protected administrative endpoints require explicit authorization evaluated against current authority and policy state.	Specifies the rule for taking a governance/runtime decision and its applicability.
Constraint	The public request/response schemas and the documented status codes of the endpoint may not be changed in this task.	Bounds the admissible space of solutions independently of who has the right to carry them out.

Policy ≠ Constraint. A Policy answers the question of the applicable decision; a Constraint, that of the admissible form of a composition or a result.

A.8. SuccessCriterion

On a narrow screen the table scrolls horizontally.

Verifiable obligation	Evidence requirement	Validation method
An unauthorized principal receives a denial.	A negative-test trace and an authorization decision record.	A call with frozen denied AuthorityCut/PolicyCut; the outcome is not Allow.
An authorized principal proceeds to the domain operation.	A positive-test trace and an action-specific Allow.	A call with frozen allowed cuts and a valid Binding.
The public API contract is unchanged.	A schema diff and a compatibility report.	A comparison of the frozen API snapshot before and after.
The security regression suite passes.	The harness version, the test list, and the raw outcomes.	All mandatory cases pass; skipped cases are retained as failure evidence.
Audit evidence has been issued.	The decision identity, the trace digest, and the retention receipt.	Schema validation and a check of the K_id/B_id/cuts/time/reason references.

A.9. CapabilityDescription and Evidence Profile

capability:source-code-modification-and-test@1.3.0 describes the inputs, outputs, effects, failure classes, and trust properties of an abstract capability. Normalization derives capability-type:repository-change-with-protected-endpoint-tests. A concrete provider appears only in the BindingCut.

Artifact type × risk class: Blueprint/Skill/Policy for a security-sensitive endpoint.
Required evidence: Provenance, an independent verifier, executable tests, negative scenarios, a compatibility report, and a current Policy review.
Independence: Producer self-approval is insufficient; the verifier and the publisher must conform to the governance profile.
Thresholds: No universal confidence threshold is specified; the numeric bounds remain empirical/governance research.

Limitations. The objects above are not standardized JSON/YAML schemas; the illustrative identifiers promise no existing repository or runtime. Security remains an empirical property of an implementation.

Summary. Managed artifacts are independently identified, versioned, and governed, and they retain provenance. A Knowledge Contract references exact compatible versions rather than duplicating their semantic content.

y="appendix-b-title">

Appendix B. An End-to-End Example of Semantic Resolution

Purpose. To show the complete transition from available context to a Resolution Receipt, a semantic Contract, and a separate IssueRecord.

Scope. The example ends at issuance; runtime binding and authorization are treated only in Appendix C.

Relation to the main text. The appendix operationalizes the Knowledge Resolver, the Resolution Receipt, and the Knowledge Contract, and introduces no additional normative requirements.

A constructed illustrative example. The same task identity and the same seven artifact lines are used as in Appendix A. The identifier values show the structure of the decision but are not measured evidence.

B.1–B.2. Example Task and Available Context

The agent must change api:/v1/admin/accounts/{account_id} while preserving the public contract, validation, the authorization guard, the negative tests, and the audit evidence. The Available Context contains approved repository records, older versions, retrieved notes, a model proposal, and the runtime tool catalog.

Available Context ≠ Selected Commitment. Material may be available, relevant, and even formally correct, yet not enter the task cut because of version, compatibility, scope, evidence, or conflict.

Approved records: The exact versions of the seven artifacts of Appendix A and their typed relations.
Historical records: Role 1.8, Skill 2.4, and Blueprint 3.9, retained for replay but not compatible with the current requirements.
Retrieved context: A design note for a public read-only endpoint; terminologically close, but task-irrelevant.
Model output: A proposal to skip the negative authorization test as "redundant"; provenance and evidence are absent.
Runtime catalog: CLI, MCP, and internal adapters; the presence of a provider does not yet enter semantic selection.

B.3. Propose

On a narrow screen the table scrolls horizontally.

Candidate	Type / version	Source	Preliminary status
R-new	Role 2.1.0	Approved governed namespace.	To be verified.
R-old	Role 1.8.0	Historical snapshot.	Outdated for Blueprint major 4.
S-new	Skill 3.0.1	Approved governed namespace.	To be verified.
S-fast	Skill proposal 3.1.0-rc	Model synthesis.	Insufficient evidence; producer self-approval.
B-protected	Blueprint 4.2.0	Approved architecture namespace.	Closure to be verified.
B-public-read	Blueprint 5.0.0	A different namespace.	Incompatible action/effects.
P-legacy	Policy 4.7.0	Historical policy set.	Conflicts with current explicit authorization Policy.

B.4. Verify

Verify reproducibly checks identity/digest, version, provenance, the Evidence Profile, the type/relation schema, compatibility, the applicable Policy, and the authority to publish or use where the profile requires it. A candidate does not acquire trust from a single high model score.

R-new, S-new, B-protected, and the four operational/governance references pass schema, evidence, and compatibility.
R-old remains historically valid but does not satisfy the version constraint of the current Blueprint.
S-fast is placed in quarantine: the required independent tests and verifier are absent.
B-public-read is rejected on mismatched action/effect requirements.
P-legacy is retained as a considered version, but the precedence profile designates the current Policy 5.0.0.

B.5. Select

Select applies the hard constraints before ranking. The search bounds are limited to the approved namespace, the historical lineage of the selected candidates, depth 4, a node budget of 120, and a provider budget of 3; these values are illustrative and are not declared to be universal defaults. The exact seven references of Appendix A are selected. The rejections are recorded with the reason codes VERSION_INCOMPATIBLE, EVIDENCE_INSUFFICIENT, EFFECT_MISMATCH, and SUPERSEDED_BY_APPLICABLE_POLICY. Residual uncertainty: an external repository outside the bounds was not examined; Search-Incomplete=false pertains only to the declared bounds.

B.6. SemanticCut

SemanticCut(q,r) contains the seven exact artifact references, the mandatory typed edges, the exclusions for a public API change and for bypassing authorization, and an unresolved declaration regarding the concrete runtime provider. No rejected candidate and no narrative rationale is included in the cut.

B.7. ResolutionCore

On a narrow screen the formula scrolls horizontally.

ResolutionCore = canon(candidate_ids, search_bounds, selected_versions, rejection_reason_codes, precedence, conflicts, uncertainty, Search-Incomplete, policy_ids)

On a narrow screen the formula scrolls horizontally.

R_id = H(bytes(ResolutionCore))

B.8. Resolution Receipt

Candidate Set: The exact identities R-new/R-old, S-new/S-fast, B-protected/B-public-read, the Policy versions, and the required operational artifacts.
Verification Results: The verdicts, validator versions, evidence identities, and scope checks for each candidate.
Selected Commitments: The seven exact references of Appendix A and the closure edges.
Rejected Alternatives: R-old, S-fast, B-public-read, and P-legacy.
Reason Codes and Precedence: The machine-readable codes and the current-approved precedence rule.
Conflicts and Resolution: The legacy Policy conflict is resolved by selecting the applicable approved version; the bypass proposal is excluded by a hard constraint.
Search Bounds: The namespaces, lineage, depth, node/provider budgets, and the moment of stopping.
Uncertainty State: Sources not examined outside the bounds are not declared to be absent.

Explanation = narrative(decision_summary, audience_profile, redactions) may have a separate E_id. Translating or editing the Explanation does not change R_id; the core and the explanation are checked against each other for the absence of semantic divergence.

B.9. Knowledge Contract

On a narrow screen the formula scrolls horizontally.

K_sem = canon(q_id, G_r[SemanticCut(q,r)], obligations, exclusions, R_id, schema_version) K_id = H(bytes(K_sem))

K_sem contains the task identity, the exact Role/Skill/Blueprint/Constraint/Policy/SuccessCriterion/CapabilityDescription references, the required graph edges, the obligations, the exclusions, R_id, and the schema version. It contains references, not copies of artifact content; the issuer, timestamp, signature, runtime adapter, and current authority are absent.

B.10. Issue Event

On a narrow screen the formula scrolls horizontally.

I = canon(K_id, issuer, authority_evidence, timestamp, signature, issuance_schema_version) I_id = H(bytes(I))

K_id ≠ I_id. The IssueRecord fixes K_id, the issuer principal, the issuance authority evidence, the timestamp, an optional signature, and the issuance schema. An authorized re-issue of the same K_sem bytes by a different issuer or at a different time creates a new I_id, but does not change K_id and does not create a new semantic Contract.

B.11. Rejection Example

If S-fast is the only Skill within the bounds, Verify returns Insufficient-Evidence. If B-protected and the current Policy are incompatible without precedence resolution, Select returns Conflict. If the budget is exhausted before closure, the result is Search-Incomplete. In all three cases no Contract and no IssueRecord are created; the system does not force closure.

Limitations. The digest literals are abbreviated and are not computed hashes; the bounds and the reason-code vocabulary are illustrative. Propose may be stochastic, whereas determinism begins with a frozen candidate set, inputs, rules, and canonicalization profile.

Summary. Context → Candidates → Verified Candidates → SemanticCut → ResolutionCore/R_id → K_sem/K_id → IssueRecord/I_id. Each arrow denotes a verifiable boundary, not automatic trust.

Appendix C. An Example of Binding and Execution Authorization

Purpose. To continue the same example after issuance and to show the independence of the Contract, the Binding, and action-specific Authorization.

Scope. Appendix C uses the existing K_id/I_id and does not repeat Resolution; IAM internals and a concrete transport are not formalized.

Relation to the main text. The appendix makes Binding and the authorization boundary concrete, along with the levels of reproducibility, and introduces no additional normative requirements.

A constructed illustrative example. The inputs are digest:K-protected-endpoint-v1 and digest:I-protected-endpoint-issue-01. The semantic commitments are not reassembled.

C.1–C.2. Input and BindingCut

BindingCut(K_id,e) considers providers for the derived CapabilityType repository-change-with-protected-endpoint-tests in the environment staging:api-service@2026-08.

On a narrow screen the table scrolls horizontally.

Provider	Transport	Semantic/effect evidence	Verdict
repository-change-adapter@7.2	Internal API	Supports a scoped patch, frozen tests, audit output, and a no-deploy effect.	Selected.
maintenance-cli@4.6	CLI	Equivalent patch/test effects, but the environment policy forbids the interactive credential path.	Compatible semantics; ineligible environment.
generic-mcp-editor@2.0	MCP	No evidence of negative-test coverage or resource-scope enforcement.	Evidence-Insufficient.

No transport is normative. Changing the provider while the semantic commitments are unchanged does not change K_id; it creates a different BindingCut and B_id.

C.3. Binding Identity

B = canon(K_id, obligation_id, CapabilityType, provider_id, interface_digest, environment_id, equivalence_evidence, verifier, validity, binding_schema_version); B_id = H(bytes(B)). This record contains no runtime credentials, only safe references. A change of provider, interface digest, or environment requires a rebind.

C.4. Contract Permission

ContractPermits(K, action) checks whether protected-endpoint:update falls within the obligations/exclusions of the frozen Contract. The predicate takes no decision about the current principal and does not prove that an implementation exists.

C.5. Binding Validity

BindingValid(B,K,action) checks the link to the exact K_id, semantic/effect equivalence, the provider/interface/environment identities, the evidence, and the period of applicability. A missing provider or invalid evidence yields Unbound.

C.6. Runtime Authorization

On a narrow screen the formula scrolls horizontally.

Auth(principal, action, resource, t | AuthorityCut(t), PolicyCut(t)) -> Allow | Deny(reason) | Indeterminate(reason)

The inputs are the principal principal:maintenance-agent-17, the action protected-endpoint:update, the resource api:/v1/admin/accounts/{account_id}, the moment t, and the exact identities of the current cuts. An Indeterminate result is fail-closed and is not reduced to Deny without retaining the reason.

C.7. Execution Gate

On a narrow screen the formula scrolls horizontally.

Executable(K,B,a,t) = ContractPermits(K,a) AND BindingValid(B,K,a) AND Auth(principal,action,resource,t | AuthorityCut(t),PolicyCut(t)) = Allow

The action lies outside the Contract. The Decision fixes K_id, B_id, where required I_id, the AuthorityCut/PolicyCut identities, the principal/action/resource, the timestamp, the outcome, and the reason. An invalid Binding and any non-Allow forbid execution.

C.8. Three Contrastive Cases

On a narrow screen the table scrolls horizontally.

Case	ContractPermits	BindingValid	Auth_t	Outcome
1. Unbound	true	false / absent	does not compute permission to execute without a valid binding	The action is not performed.
2. Deny	true	true	Deny(reason)	The action is not performed.
3. Allow	true	true	Allow	The action is admitted to execution.

C.9. Authority Change Over Time

At t1 the AuthorityCut contains a valid scoped grant and Auth_t1=Allow. At t2 that same grant has been revoked, so with K_id and B_id unchanged the result is Auth_t2=Deny(REVOKED_GRANT). The semantic validity of the Contract is not rewritten; what changes is runtime executability.

C.10. Binding Gap

If no provider confirms the required effects/trust properties in the environment, GapKind=BindingProvider remains an operational BindingGap and terminates in Unbound. It does not trigger Knowledge Expansion automatically: a missing implementation, an unavailable environment, and insufficient evidence must first be distinguished. Insufficient authority remains an authorization failure, not a Gap.

C.11. Historical Replay

Semantic reproducibility: The exact artifact versions, SemanticCut, R_id, and K_id are restored.
Decision reproducibility: The Receipt, rejected alternatives, bounds, precedence, conflicts, I_id, and the applicable cut identities explain the selection and the admission.
Operational reproducibility: B_id, the environment, the action decision, and the execution evidence are reproduced if the provider/runtime dependency is still available.

If an external provider has been removed, semantic and decision replay may remain possible while bit-for-bit operational replay does not. The architecture does not promise absolute reproducibility of external infrastructure.

Limitations. AuthorityCut/PolicyCut are bounded interfaces, not a complete IAM formalization. The example does not prove security; it makes policy, evidence, authority boundaries, and decisions explicit and verifiable.

Summary. The Knowledge Contract specifies what is semantically permitted and required; the Binding determines the realization of an abstract capability; Auth_t determines whether the resulting action is permitted at the time of execution.

Appendix D. Evaluation and Preregistration Details

Purpose. To fix the reproducible but not yet executed experimental programme of Meaning Management v1.

Scope. The appendix contains hypotheses, protocols, datasets, baselines, ablations, metrics, and decision rules; outcomes are absent.

Relation to the main text. The appendix makes the experimental programme of Part V concrete and introduces no additional normative requirements into the architecture.

Experimental content. This is a preregistration specification. Neither D1–D6 nor EXP-001–009 are declared to have been executed; the synthetic mechanics checks of the publication package are not experimental outcomes.

D.1. Hypotheses

On a narrow screen the table scrolls horizontally.

Hypothesis	Research question	Expected direction	Falsification condition
HYP-001 · Completeness	Does B4 improve the completeness of the correct semantic cut relative to retrieval/flat-manifest baselines?	Higher precision/recall without an increase in conflicting inclusions.	The preregistered margin/gain is not reached, or the effect disappears on the holdout.
HYP-002 · Policy safety	Does separating the Contract, the Binding, and Auth_t reduce the number of hard-policy violations?	Fewer violations and governance false negatives.	There is no preregistered reduction, or privilege amplification appears.
HYP-003 · Replay	Do separate ResolutionCore, Contract, and issuance identities improve the reproducibility of decisions?	Higher replay of each frozen identity domain without cross-domain drift.	Issue metadata changes K_id, the narrative changes R_id, or a frozen domain is not reproduced.
HYP-004 · Revocation without history rewrite	Are historical bytes preserved when the current authority changes?	Historical identity stable; revoked action is not allowed.	Any change of historical bytes, or Allow after an effective revocation.
HYP-005 · Conflict diagnostics	Does typed Select plus the Receipt improve reproducible diagnostics of conflicts and gaps?	Higher reconstruction adequacy and gap precision/recall.	The conflict is not reconstructed, or the diagnostics do not surpass the baseline.
HYP-006 · Bounded recursion	Does BKG traversal terminate within the bounds with an honest terminal state?	Termination within B and explicit Search-Incomplete when closure is not established.	Timeout/overrun, hidden incompleteness, or a forced Closed.
HYP-007 · Transport equivalence	Does a semantic BindingCut improve the recognition of equivalent and non-equivalent providers?	Higher compatibility precision/recall and fewer false accepts.	An incompatible adapter is accepted, or the effects diverge.
HYP-008 · Cost	Is the overhead of B4 justified by the observed error/replay gain?	Not specified; acceptability depends on the preregistered risk-class trade-off.	The overhead exceeds the gain, or B2/B3 is equivalent at a lower cost.
HYP-009 · Ontology agreement	Do the Variant A rules improve inter-expert agreement on the types and the forbidden merges?	Higher agreement and fewer systematic conflations.	Low agreement, or a persistent conflation of types.

D.2. Experimental Protocols

On a narrow screen the table scrolls horizontally.

Hypothesis	Protocol	Dataset	Baseline	Intervention	Primary metric	Threshold status	Decision rule
HYP-001	EXP-001	D1: a frozen stratified split and a holdout.	B1/B2, the same universe and budget.	B4 with closure, the Receipt, and the Contract.	Artifact precision/recall; terminal states.	TBD before preregistration: the precision margin and a meaningful recall gain.	A paired stratified bootstrap confidence interval; both bounds and the holdout.
HYP-002	EXP-002	D2: fixed policy attacks by risk stratum.	B0/B1; B3 as a strong comparator.	B4 with a separate Contract, BindingCut, and Auth_t.	Critical-error gain and governance false negatives.	TBD before preregistration: the maximum rate and a meaningful reduction.	A paired exact McNemar test and a confidence interval; failures/abstentions in the denominator.
HYP-003	EXP-003	D1: frozen semantic/issue inputs and seeds.	B1/B3.	B4 with ResolutionCore/R_id, K_sem/K_id, and I/I_id.	Replay gain across the three identity domains.	TBD before preregistration: the replay gain; canonical drift is always a failure.	A paired bootstrap confidence interval, exact identity comparison, and divergence classes.
HYP-004	EXP-004	D3: histories before and after an effective revocation.	B3 with mutable state.	B4 with pinned identities, current cuts, and Auth_t.	Historical byte stability; the current Auth outcome.	Defined invariant: bytes stable; revoked action not Allow.	Property-based replay; any counterexample rejects the property.
HYP-005	EXP-005	D2: conflicts/gaps with an adjudicated oracle.	B1, a free-text planner.	B4 with typed Select and the Receipt.	Conflict reconstruction and GapKind precision/recall.	TBD before preregistration: the improvement and the blinded agreement bound.	Blind paired assessment; a permutation test chosen in advance, or a bootstrap interval.
HYP-006	EXP-006	D2: cyclic/deep graphs and bounds B.	B1 without a terminal-state contract.	B4 with bounded traversal and Search-Incomplete.	Termination, state, expansions, budget overrun.	Defined invariant: declared state within B without a completeness promise.	Property-based traversal; any counterexample rejects the property.
HYP-007	EXP-007	D4: positive/negative adapter pairs.	B3 by interface/transport.	B4 BindingCut by semantics and trust domain.	Compatibility accuracy and effect agreement.	TBD before preregistration: precision/recall and the false-accept maximum.	An adjudicated oracle; McNemar and a confidence interval for effect agreement.
HYP-008	EXP-008	D1-D4: complete cost logs.	B3 under equal budgets/adapters.	B4: first resolution and replay separately.	Resolution/context overhead with critical-error/replay gain.	TBD before preregistration: the overhead and the gain by risk class.	Paired bootstrap intervals and a preregistered cost-effectiveness rule.
HYP-009	EXP-009	D5: independent double annotation and adjudication.	Annotation without the Variant A rules.	The seven types and the forbidden conflations.	Inter-annotator agreement and a confusion matrix.	TBD before preregistration: the agreement and the lower confidence bound.	Kappa/alpha is chosen before the run; a bootstrap interval and a permutation comparison.

D.3. Datasets

D1 — Canonical task fixtures: Tasks from the original Research 17 corpus with manually fixed required artifacts, relations, and admissible terminal states.
D2 — Adversarial semantic fixtures: Omissions, conflicting versions, malicious Policy, misleading retrieval, an underspecified SuccessCriterion, and plausible synthesized gaps.
D3 — Evolution histories: Chains of successors, revocations, delayed evidence, and historical replay points.
D4 — Transport and binding fixtures: Semantically equivalent and non-equivalent CLI, API, MCP, and A2A adapters with controlled differences in effects.
D5 — Double-annotation corpus: Independent expert annotation of Role, Skill, Blueprint, and the four operational/governance types.
D6 — External Naturalistic Task Corpus: A future corpus independent of the Variant A construction, with natural ambiguity, missing knowledge, Policy conflicts, and tool bindings. As of the semantic/preregistration freeze, corpus D6 has not been collected; no results exist.

Each frozen dataset version requires a digest, a data statement, inclusion/exclusion rules, a label schema, an adjudication log, and a split identity. D6 is a future external naturalistic corpus; it has not been collected, and no outcomes exist.

D.4. Baselines

B0 — Prompt-only: Context without typed artifacts or receipts.
B1 — Retrieval + planner: RAG and a planner without a contract cut.
B2 — Flat manifest: Exact versions without BKG closure, typed failures, or a separate Auth.
B3 — Workflow + policy engine: Workflow and policy-as-code without provenance-aware semantic selection.
B4 — Full proposed profile: The complete Meaning Management v1 construction.

Task inputs, the candidate universe, budgets, and adapters must coincide wherever the comparison does not deliberately change them. Additional retrieval calls, human review, and storage are counted as treatment cost.

D.5. Ablations

The four single-component ablations do not constitute a full factorial design and do not prejudge the usefulness of a component.

On a narrow screen the table scrolls horizontally.

Ablation	What it isolates	Causal question
B4 without the Resolution Receipt	The contribution of decision provenance and diagnosability.	Do replay of the selection, recovery of reasons, and diagnostics change while the Contract and the remaining checks are preserved?
B4 without bounded BKG closure	The contribution of structured bounded semantic resolution.	Do completeness, conflict detection, Search-Incomplete, and cost change under the same candidate universe?
B4 without separate Authorization	The contribution of separating semantic permission from runtime authority.	Do policy violations and false allow/deny change if Auth_t is not separated from the Contract and the Binding?
B4 without Evidence Profiles	The contribution of risk/type-dependent admission governance.	Do false acceptance, abstention, and human-review cost change without profile-specific evidence requirements?

D.6. Metrics

On a narrow screen the table scrolls horizontally.

Metric group	Definition	Unit	Aggregation	Direction	Known limitations
Resolution/context overhead	Additional latency, model tokens, memory, graph operations, and human-review time relative to a comparable baseline.	ms, tokens, bytes, graph operations, person-minutes	Median, tail quantiles, and the stratified paired difference by task/risk class.	Lower, while the error/replay gain is preserved.	The task budget and candidate universe must be identical; first resolution and replay are counted separately.
Critical-error gain	The change in the rate of critical semantic, policy, and binding errors relative to the baseline.	percentage points and relative risk	By risk class, with failures and abstentions in the denominator.	A larger positive reduction in errors.	Severity weighting and the practically meaningful minimum must be frozen before the main outcomes.
Replay gain	The change in the proportion of repetitions with the same terminal state and, separately, the same R_id, K_id, and I_id under frozen inputs of the corresponding domain.	proportion and percentage-point difference	By identity domain and by class of admissible divergence.	Higher under unchanged frozen inputs.	Narrative drift does not change R_id; issue metadata drift must not change K_id.
Search-Incomplete rate	The proportion of tasks that ended in an explicit Search-Incomplete under the declared bounds.	proportion	By bounds, risk class, and graph depth.	Lower, without hidden coercion into Closed.	A zero proportion may indicate a defect of observability rather than completeness.
Assembly failure rate	The proportion of selected cuts not issued because of canonicalization, Receipt, schema, or Issue authority failure.	proportion by failure class	Technical assembly and Issue-Unauthorized separately.	Lower, while fail-closed semantics is preserved.	Issue-Unauthorized must not be counted as a serialization error or removed from the denominator.
Inter-annotator agreement	Agreement among independent experts on the seven types, relation types, conflicts, and terminal states.	Cohen’s kappa or Krippendorff’s alpha and a confusion matrix	The coefficient and a confidence interval under a profile chosen in advance.	Higher, with no systematic conflations.	The metric and the lower bound are chosen before the run; class imbalance is analysed separately.
Compatibility accuracy	Precision/recall of the compatibility of semantic cuts and bindings against adjudicated fixtures.	precision, recall, false-accept rate	By relation type, adapter effects, and risk class.	Higher precision/recall and fewer false accepts.	A matching interface name or transport does not prove semantic compatibility.
Governance false-positive rate	The proportion of admissible publications, issuances, bindings, or actions wrongly rejected by the governance profile.	proportion	By decision surface and risk class.	Lower, without trivially permitting everything.	A governance reject must be distinguished from a technical failure, and human-review cost must be counted.
Governance false-negative rate	The proportion of inadmissible publications, issuances, bindings, or actions wrongly permitted by the governance profile.	proportion with severity weighting	By decision surface, risk class, and consequence class.	Lower.	A mean proportion without severity may conceal rare critical errors.

D.7. Thresholds and Preregistration Freeze

Any numeric threshold without a definition-derived invariant has the status TBD before preregistration. It is chosen on the basis of pilot data, power analysis, consequence severity, and risk appetite before the main outcomes are inspected; a subsequent change is marked as exploratory analysis.

On a narrow screen the table scrolls horizontally.

Quantity	Status	Constraint on the choice
Resolution/context overhead	TBD before preregistration	The task budget and candidate universe must be identical; first resolution and replay are counted separately.
Critical-error gain	TBD before preregistration	Severity weighting and the practically meaningful minimum must be frozen before the main outcomes.
Replay gain	TBD before preregistration	Narrative drift does not change R_id; issue metadata drift must not change K_id.
Search-Incomplete rate	TBD before preregistration	A zero proportion may indicate a defect of observability rather than completeness.
Assembly failure rate	TBD before preregistration	Issue-Unauthorized must not be counted as a serialization error or removed from the denominator.
Inter-annotator agreement	TBD before preregistration	The metric and the lower bound are chosen before the run; class imbalance is analysed separately.
Compatibility accuracy	TBD before preregistration	A matching interface name or transport does not prove semantic compatibility.
Governance false-positive rate	TBD before preregistration	A governance reject must be distinguished from a technical failure, and human-review cost must be counted.
Governance false-negative rate	TBD before preregistration	A mean proportion without severity may conceal rare critical errors.

Before the main experiment the following are frozen:

dataset versions
baseline implementations
model/runtime versions
prompts where applicable
artifact repository snapshot
metrics
aggregation rules
thresholds
exclusions
stopping rules
statistical procedure
random seeds where applicable

D.8. Decision Rules

On a narrow screen the table scrolls horizontally.

Protocol	Success	Failure	Inconclusive
EXP-001	The decision rule specified in advance confirms the expected direction and the frozen threshold.	The preregistered margin/gain is not reached, or the effect disappears on the holdout.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-002	The decision rule specified in advance confirms the expected direction and the frozen threshold.	There is no preregistered reduction, or privilege amplification appears.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-003	The decision rule specified in advance confirms the expected direction and the frozen threshold.	Issue metadata changes K_id, the narrative changes R_id, or a frozen domain is not reproduced.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-004	The decision rule specified in advance confirms the expected direction and the frozen threshold.	Any change of historical bytes, or Allow after an effective revocation.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-005	The decision rule specified in advance confirms the expected direction and the frozen threshold.	The conflict is not reconstructed, or the diagnostics do not surpass the baseline.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-006	The decision rule specified in advance confirms the expected direction and the frozen threshold.	Timeout/overrun, hidden incompleteness, or a forced Closed.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-007	The decision rule specified in advance confirms the expected direction and the frozen threshold.	An incompatible adapter is accepted, or the effects diverge.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-008	The decision rule specified in advance confirms the expected direction and the frozen threshold.	The overhead exceeds the gain, or B2/B3 is equivalent at a lower cost.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.
EXP-009	The decision rule specified in advance confirms the expected direction and the frozen threshold.	Low agreement, or a persistent conflation of types.	The quality or volume of the frozen data is insufficient, or the interval does not permit classifying the result against the frozen threshold.

D.9. Failure Interpretation

A negative or inconclusive outcome does not reduce to the single phrase "hypothesis rejected". Before interpretation, the following explanations are distinguished:

the architecture is not required for this class of tasks
an individual component makes no distinguishable contribution
the implementation is inadequate
the dataset is inadequate
the metric does not correspond to the property under test
the ontology is unstable
the burden is excessive

D.10. Architecture Rejection Criteria

The corresponding component, or the whole of Meaning Management v1, is to be simplified, partly rejected, or rejected entirely if a preregistered condition holds:

There is no material reduction of critical semantic, policy, or binding errors.
The resolution/context overhead is excessive relative to the errors prevented.
Independent annotators do not reach stable agreement.
Search-Incomplete persists systematically on naturalistic tasks under reasonable bounds.
Frozen inputs do not reproduce the terminal state and the corresponding R_id/K_id/I_id.
The cost and errors of governance exceed the observed gains.
B2 or B3 provides equivalent guarantees at a substantially lower cost.

After the main outcomes, the dataset, metric, threshold, or denominator may not be changed in order to turn such an outcome into a success.

Limitations. The dataset versions, sample sizes, thresholds, statistical profiles, and the implementation under test have not yet been frozen. No row is a result; D6 does not exist as a corpus.

Summary. Appendix D links the nine hypotheses to the nine protocols and admits in advance the possibility of failure, an inconclusive outcome, simplification of a component, and rejection of the architecture.