Source-linked AI summary

ContextNest: Verifiable Context Governance for Autonomous AI Agent

Misha Sulpovar, Benn R. Konsynski, Qaish Kanchwala, Gabe Goodhart

arXiv:2607.02116v2cs.AI

TL;DR

Autonomous AI agents are moving beyond text generation into operational roles, including answering policy questions, drafting decisions, coordinating workflows, invoking tools, and acting for organizations. ContextNest specifies a governance layer beneath retrieval, using typed documents, deterministic selection, version histories, checkpoints, and audit traces to govern agent-consumable knowledge. Governed selection strictly Pareto-dominates BM25 sparse retrieval on a controlled stale-version attack, while dense+HNSW is non-deterministic on 80% of queries with mean Jaccard 0.611 and worst case 0.210.

  • Problem

    Autonomous AI agents are moving beyond text generation into operational roles, including answering policy questions, drafting decisions, coordinating workflows, invoking tools, and acting for organizations.

    Source: §1 · p. 1
  • Method

    ContextNest specifies a governance layer beneath retrieval, using typed documents, deterministic selection, version histories, checkpoints, and audit traces to govern agent-consumable knowledge.

    Source: §1.1 · p. 5, §1.2 · p. 5
  • Results

    Governed selection strictly Pareto-dominates BM25 sparse retrieval on a controlled stale-version attack, while dense+HNSW is non-deterministic on 80% of queries with mean Jaccard 0.611 and worst case 0.210.

    Source: Discussion · p. 27, §13 · p. 32
  • Takeaways & Limitations

    ContextNest supplies the governance substrate beneath retrieval, and deterministic selection supports reconstructing the knowledge basis of prior agent outputs.

    Source: Discussion · p. 27, §13 · p. 32

    The specification does not include a built-in semantic retriever; similarity search requires a configured retrieval backend.

    Source: §12.1 · p. 29

Abstract

from arXiv · show

Autonomous AI agents increasingly depend on external knowledge stores, yet most retrieval pipelines provide relevance without durable guarantees of provenance, version identity, integrity, traceability, or point-in-time reconstruction. We formalize this as context governance and present ContextNest, an open specification and reference implementation for governed AI-consumable knowledge vaults. ContextNest does not replace Retrieval-Augmented Generation (RAG); it supplies the governance layer beneath retrieval, determining which artifacts are approved, current, attributable, and integrity-verified before retrieval systems operate over them. The specification combines typed Markdown documents with metadata, deterministic set-algebraic selectors, contextnest:// URI references, SHA-256 hash-chained version histories, graph-level checkpoints, source nodes for live data through the Model Context Protocol (MCP), and audit traces of agent context consumption. These mechanisms let organizations reconstruct which knowledge versions informed an agent output and whether those versions were AI-eligible when consumed. We report first empirical results from two controlled experiments. In a stale-version attack isolating the governance-versus-retrieval failure mode, governed selection strictly Pareto-dominates BM25 sparse retrieval, with higher answer-quality pass rate (97% versus 93-90%) at about one-third the input-token cost. In a retrieval-determinism experiment over a 1,060-document corpus, deterministic selectors and BM25 return stable document sets across repeated identical queries (Jaccard 1.0), while a dense+HNSW baseline is non-deterministic on 80% of queries (mean Jaccard 0.611, worst case 0.210). These results suggest that context governance addresses failure modes retrieval quality alone is not designed to resolve. We release a core engine, CLI, and MCP server under open licenses.

1 Introduction

ContextNest addresses the gap between retrieving relevant information and ensuring an agent consumes approved, current, attributable, and auditable knowledge. It provides a governance layer that complements retrieval, with typed documents, deterministic selection, version histories, checkpoints, and audit traces.

1 Introduction

  • Most agent knowledge pipelines lack durable answers about which source version informed an output, who approved it, whether it was current, and whether it can be reconstructed.The procurement vignette illustrates how an archived but relevant policy can be surfaced without a record of the consumed version.Source: §1 · p. 2
  • ContextNest treats context as a governed artifact and supplies typed Markdown, deterministic selectors, addressable references, hash-chained histories, checkpoints, and injection traces.It governs the published, integrity-verified subset; retrieval systems operate over that subset rather than being replaced.Source: §1 · pp. 2–3, §1.1 · p. 4
  • ContextNest’s controlled stale-version attack demonstrates two BM25 failure modes, while the paper reports that governed selection strictly Pareto-dominates BM25 sparse retrieval on the suite.The attack isolates governance versus retrieval; the contribution passage also reports a separate 50-query determinism experiment on a 1,060-document corpus.Source: §1 · p. 3
  • ContextNest specifies inference-time knowledge governance, not the full action-authorization stack or training-data governance.Agent identity, tool-call policy enforcement, and outcome authorization are complementary layers scoped to future work.Source: §1 · p. 4

1.1 ContextNest and RAG are Complementary

  • ContextNest and retrieval answer different questions: governance determines which documents are eligible, while RAG finds relevant passages within the governed subset.The proposed composition indexes published, integrity-verified documents and gives the agent retrieved passages alongside an audit trace.Source: §1.1 · pp. 4–5

1.2 Architectural Overview

  • The architecture combines typed Markdown documents, a graph implicit in references and tags, hierarchical stewardship, hash-chained histories with checkpoints, and injection-level audit records.The overview describes human governance from authoring and review through publication, followed by runtime resolution, injection, and consumption.Source: §1.2 · p. 5, Figure 2 · p. 6

2 Related Work

Related work improves retrieval, models structured knowledge, versions files, and tracks provenance, but these strands do not themselves provide ContextNest’s inference-time governance layer. ContextNest retains authored documents while adding metadata, references, version semantics, and auditability.

2.1 Retrieval-Augmented Generation

  • RAG advances improve retrieval relevance, but the abstraction does not provide authorship tracking, version control, tamper detection, or per-output version audit trails.Deployments may add such governance infrastructure, but it is external to the retrieval mechanism.Source: §2.1 · p. 6

2.2 Knowledge Graphs and Structured Knowledge

  • ContextNest keeps documents in authored Markdown and uses frontmatter and contextnest:// references to provide queryable structure without semantic decomposition.The related-work passage contrasts this with knowledge graphs’ entity extraction and relationship typing, which can discard nuance and context-dependent meaning.Source: §2.2 · p. 7

2.3 Version Control for Data and Documents

  • Git, DVC, and LakeFS version files or artifacts, whereas ContextNest’s document-level history also records authorship and publication status for governed knowledge.Its hash chain supports independent integrity verification without a centralized server.Source: §2.3 · p. 7

2.4 Model Context Protocol

  • ContextNest’s MCP server exposes vault operations as tools, and source nodes declaratively specify MCP tool calls for live-data hydration.MCP standardizes context provision through a client-server architecture.Source: §2.4 · p. 7

2.5 Data Provenance and Audit Trails

  • ContextNest extends provenance to inference-time knowledge by recording which documents informed an interaction, who authored them, and whether they were later tampered with.The cited provenance work has focused primarily on training-data documentation and model cards [Mitchell et al., 2019].Source: §2.5 · p. 7

2.6 Trustworthy Agentic Systems and Cross-Organizational Standards

  • ContextNest is framed as an inference-time knowledge-governance substrate compatible with cross-organizational standards and trustworthy-agent systems.The cited lineage links trustworthy delegation to grounded, attributable, auditable knowledge [Konsynski and Sviokla, 1994, Konsynski et al., 2024].Source: §2.6 · pp. 7–8

2.7 Regulatory Context

  • The section describes transparency and data-governance requirements in the EU AI Act [European Parliament, 2024] and NIST AI Risk Management Framework as practical motivations for auditable knowledge governance.It also notes that SOC 2 audits increasingly examine AI data provenance.Source: §2.7 · p. 8

3 Problem Formalization

The paper defines context governance through six properties and argues that standard RAG does not provide them as part of its retrieval abstraction. It specifies the threat assumptions under which ContextNest’s integrity claims apply.

3 Problem Formalization

  • Context governance is the set of properties required for external knowledge consumption to be auditable, trustworthy, and compliant with organizational and regulatory requirements.The formal model represents a context system through documents, versions, an append-only checkpoint log, and an access log.Source: §3 · p. 8
  • The six properties are provenance, version identity, integrity, deterministic selection, traceability, and temporal consistency.Together they require attributable versions, tamper detection, pure selection, output-linked access records, and bit-identical reconstruction at past checkpoints.Source: §3 · p. 8
  • Standard embedding-index RAG does not provide Properties 1–6 as part of its retrieval abstraction, though production systems may layer on external infrastructure.The proposition is architectural, not a claim that deployed systems cannot add governance mechanisms.Source: §3 · p. 9
  • The RAG counterexamples concern missing mechanisms: authorship metadata, per-document version sequences, chained integrity checks, pure selection, version-specific access records, and snapshots.The passage attributes these gaps to the abstraction rather than a particular implementation choice.Source: §3 · p. 9
  • The paper presents ContextNest as satisfying the six properties and specifies the adversaries against which its integrity property holds.The stated integrity claim concerns detection of modification, not prevention.Source: §3 · p. 9, §3.1 · p. 9

3.1 Threat Model

  • A per-document chain hash makes content tampering and changes to bound author, timestamp, or ordinal metadata detectable by breaking the chain from the altered version onward.The history-rewriter threat includes changing attribution, backdating an edit, or splicing the version sequence.Source: §3.1 · p. 9
  • Checkpoint hashes bind to document-chain hashes, while checkpoint-pinned URIs, default-to-latest resolution, and audit traces address stale-version induction.The trace exposes a stale consumed version post hoc even if it does not prevent staleness in real time.Source: §3.1 · pp. 9–10
  • ContextNest does not prevent tampering by authorized writers, ensure confidentiality or availability, or stop stewards from approving misinformation.Agent identity attacks are also outside scope and assigned to complementary attestation mechanisms scoped to future work.Source: §3.1 · p. 10

4 Document Model

ContextNest structures knowledge as typed, status-gated Markdown documents in a vault, with stewardship rules governing who can approve content. Its model distinguishes governance modes and roles, enforces separation of duties in governed vaults, and links approvals to auditable histories.

4.1 Structure; 4.2 Node Types

  • Typed Markdown documents use node types to classify an agent’s intended use of each document, rather than its subject matter.The fixed types enable type-selective queries and differential treatment by consuming agents.Source: §4.1 · p. 10, §4.2 · p. 10

4.3 Document Status

  • Only published documents are eligible for context injection, creating a binary gate against work-in-progress knowledge reaching agents.The resolver excludes drafts from query results.Source: §4.3 · pp. 10–11

4.4 Vault Structure

  • A vault has a defined directory layout, with CONTEXT.md supplying its identity and instructions and context.yaml indexing documents and relationships.The layout also includes configuration, knowledge documents, version history, source nodes, and saved context packs.Source: §4.4 · p. 11

4.5 Stewardship Model

  • Stewardship binds principals to vault subsets and provides the authority rules for moving documents into published status.The model preserves artifact-level accountability through an auditable authorship and approval chain.Source: §4.5 · p. 11

4.5.1 Scope Hierarchy

  • Stewardship resolves document responsibility in priority order, with the first matching steward governing review, approval, or read access.Table 2 specifies priority resolution and breaks ties at the same scope by the most-specific match.Source: §4.5.1 · p. 11, Table 2 · p. 12

4.5.2 Role Lattice; 4.5.3 Governance Modes

  • Stewards hold roles that can vary by scope, while each vault selects whether its stewardship enforcement is active.Ungoverned mode auto-approves new documents; governed mode starts them as drafts and requires a non-author Reviewer for approval.Source: §4.5.3 · p. 12, §4.5.2 · p. 12, Table 3 · p. 12

4.5.4 Separation of Duties

  • In governed mode, the principal publishing a draft must differ from its author, and the API enforces this separation at the system boundary.Even a Reviewer cannot approve a version they authored.Source: §4.5.4 · p. 13

4.5.5 Relation to Property 5 (Traceability)

  • Approval events are recorded in version history, linking each consumed version to the principal who authorized its AI eligibility.The approval record inherits chain-hash protections, so retroactive rewriting invalidates the chain.Source: §4.5.5 · p. 13

5 Selector Grammar

ContextNest selectors provide deterministic, set-algebraic document selection over published documents. Their grammar supports named packs and efficient evaluation without scanning the full vault.

5 Selector Grammar

  • Selectors use set algebra to return identical results for identical queries, unlike embedding-based retrieval.This deterministic selection satisfies Property 4.Source: §5 · p. 13

5.1 Formal Grammar

  • The selector grammar combines terms, factors, and atoms, including tags, URIs, packs, and metadata filters.The operator table gives precedence as () > + > - > |.Source: §5.1 · p. 13, Table 4 · p. 14

5.2 Operator Semantics

  • Selector operators perform set operations over published documents, with parentheses, intersection, difference, and union ordered by precedence.The supplied operator table specifies the precedence order.Source: §5.2 · p. 13, Table 4 · p. 14

5.3 Complexity

  • Evaluation runs in O(|S|·p̄+r), using write-maintained posting lists so selectors avoid a full vault scan.Pack expansion adds at most a constant factor because packs cannot nest recursively.Source: §5.3 · p. 14

5.4 Context Packs

  • Named context packs store selector expressions with optional agent instructions and can combine static documents with source nodes.The resolver hydrates sources according to declared dependency ordering.Source: §5.4 · p. 14

6 Addressable Context Scheme

ContextNest URIs provide addressable references with distinct resolution modes, while SHA-256 hash chains make document histories tamper-evident. The scheme supports pinned references, deterministic structural selection, and explicit delegation to external retrieval backends.

6 Addressable Context Scheme; 6.1 URI Grammar

  • ContextNest URIs encode direct, set, or delegated resolution classes, with the URI form determining the class syntactically.The patterns are defined by the URI grammar and summarized in Table 5.Source: §6.1 · p. 14, §6 · p. 14, Table 5 · p. 14

6.2 Resolution Modes

  • Floating resolution returns the latest published version, whereas pinned resolution returns the version recorded at a specified checkpoint for audit replay.Pinned references provide a checkpoint-consistent view of the knowledge graph.Source: §6.2 · p. 15

6.3 Direct, Set, and Delegated Resolution

  • Direct addressing resolves a specified document or section, and set addressing deterministically selects published documents by tag or folder.Delegated search URIs hand retrieval to a configured backend; the specification does not define its algorithm.Source: §6.3 · p. 15
  • Delegated retrieval is not generally deterministic, but its resolved document set and each returned document’s chain hash are recorded in the audit trace.Direct or set addressing is the specified choice when Property 4 is required.Source: §6.3 · p. 15

6.4 Namespace Federation

  • Vaults can use anonymous, federated, or scoped namespaces to support cross-vault references, including allow-list restrictions in scoped mode.Federation lets teams maintain independent vaults while referencing one another.Source: §6.4 · p. 16

6.5 URI Canonicalization

  • URI canonicalization resolves dot segments, rejects consecutive slashes, normalizes percent-encoding, lowercases authorities, and preserves case-sensitive path segments.Non-canonical representations of the same URI must resolve identically.Source: §6.1 · p. 15, §6.5 · p. 16

7 Integrity Verification; 7.1 Document Version Chains; 7.2 Version Storage Model

  • SHA-256 hash chains detect modifications to document history, while keyframes and diffs store versions compactly and allow reconstruction.Changing any entry’s content, attribution, timestamp, or position invalidates subsequent chain hashes; keyframes default to every tenth version.Source: §7.1 · p. 16, §7 · p. 16, §7.2 · pp. 16–17

8 Checkpoint System

Per-document version histories alone cannot preserve a consistent cross-document state. ContextNest checkpoints bind published document versions and chain hashes into a graph snapshot that can be verified, reconstructed, and rebuilt from intact histories.

8 Checkpoint System

  • A checkpoint provides an atomic snapshot of the knowledge graph, addressing cross-document changes that can alter references when a document is republished.Without a checkpoint, a reference may resolve to a new version and break assumptions made by its author.Source: §8 · p. 17

8.1 Checkpoint Creation

  • Each publication creates a checkpoint recording its sequence number, triggering document, published-document version map, chain-hash map, and chained checkpoint hash.The log is append-only.Source: §8.1 · p. 17

8.2 Checkpoint Hash Construction

  • Checkpoint hashes bind canonical version and chain-hash maps, allowing verification that checkpointed hashes match document histories.A mismatch indicates a document history was rewritten after checkpoint creation.Source: §8.2 · p. 17

8.3 Temporal Reconstruction

  • Given checkpoint N, the system reconstructs the graph by rebuilding each recorded document version and verifying its chain hash, enabling audit replay.This satisfies Property 6 (temporal consistency).Source: §8.3 · p. 17

Complexity.

  • Reconstruction requires O(|D_n|·k) work and checkpoint verification O(|D_n|) hash comparisons, both linear in published-vault size at checkpoint n.Reconstruction cost depends on the keyframe interval k.Source: Complexity · p. 18

8.4 Checkpoint History Rebuild

  • A lost or corrupted checkpoint log can be deterministically rebuilt by sorting publication events from intact document histories and replaying them.The rebuilt log is equivalent to the original checkpoint log.Source: §8.4 · p. 18

9 Context Injection and Tracing

ContextNest resolves and logs governed context for agents, while its anchored-URI approach supports selective access to large documents with provenance and traceability. Audit traces record what was consumed and can serve as evidence for accountable review.

9.1 Injection Protocol

  • The resolver evaluates selectors, orders source nodes by dependency, returns documents with version metadata, and logs each access for audit tracing.The agent—not the resolver—decides whether and how to act on returned documents, and executes source-node instructions.Source: §9.1 · p. 18

9.2 Audit Trace Schema

  • Each access trace records document URI, consumed version, checkpoint, author, edit time, and access time; source hydration adds tool, server, result-hash, cache, and duration fields.These records support traceability, and the paper describes the trace as a durable, machine-verifiable evidence bundle for the knowledge basis of an agent action; it does not close the agent-identity gap.Source: §9.2 · p. 18

9.3 Sub-document Selection for Large Documents

  • For small or medium documents, whole-document injection is appropriate, but it can be wasteful or infeasible for large authored documents.Anchored contextnest:// URIs resolve a named section and its successor with the same metadata as whole-document resolution; traces record the consumed anchor range. Anchors can also cross-reference remote vault sections or support delegated retrieval at section granularity, provided sections are indexed explicitly.Source: §9.3 · pp. 18–19
  • The specification leaves the anchoring discipline open, requiring only deterministic resolution and inclusion of the anchor identifier in the audit trace.Source: §9.3 · p. 19

10 Source Nodes: Live Data Integration

ContextNest represents live-data retrieval instructions as governed source nodes and separates hydrated results from durable knowledge. Its staged state can retain captured external content for later audit while keeping it excluded from agent-eligible context by default.

10 Source Nodes: Live Data Integration

  • Source nodes are governed knowledge-graph documents containing instructions for fetching live context from external services.Source: §10 · p. 19

10.1 Declarative Specification

  • Source-node frontmatter declares transport, server, tools, dependencies, and cache TTL, while the body instructs the agent how to call tools and interpret results.Source: §10.1 · p. 19

10.2 Dependency Resolution

  • The resolver topologically orders source nodes by their declared dependencies, and validation rejects circular dependencies.Source: §10.2 · p. 19

10.3 Result Lifecycle

  • Hydrated results remain session-scoped and outside vault versioning and integrity mechanisms; human-reviewed results can be promoted as standard documents referencing their source nodes.Source: §10.3 · p. 20

10.4 The Staged Source-Node Lifecycle State

  • Session-scoped hydration leaves an audit gap when external state changes, because traces retain result hashes but not the hydrated content.The staged state captures attributable, integrity-verified content in the vault, excludes it from agent-eligible context by default, and allows steward promotion or garbage collection after configurable retention. Staging lets auditors reconstruct consumed evidence after external sources change, within the retention window.Source: §10.4 · pp. 20–21
  • Staged entries can be promoted by a steward into the durable lifecycle or garbage-collected after a configurable retention window, with audit events and chain verification preserved.Capture policy can vary by vault and source; staged entries carry hydration and source metadata, and their content and sequence are protected by per-source chain hashes.Source: §10.4 · pp. 20–21

11 Reference Implementation and Empirical Validation

ContextNest’s reference implementation is presented alongside preliminary evaluations of governed selection and retrieval determinism. In a stale-version attack, the selector strictly Pareto-dominates both BM25 conditions, while selector and BM25 are perfectly deterministic in the reported repeated-query test.

11 Reference Implementation and Empirical Validation

  • The reference implementation comprises a core engine, a 19-command CLI, and an MCP server; the tool invocations produce audit-log entries with resolved node, consumed version, checkpoint, and principal.The packages are released under AGPL-3.0, while the specification is under Apache-2.0; the paper also states that the specification, implementation packages, experimental harness, fixture vault, and rubrics are openly available.Source: §11 · p. 22, §11.4 · p. 27

11.1 First Empirical Results

  • In the first 10-query E1 run, selector input-token use was about one-third of BM25’s, while BM25 passed one more query.The authors call this preliminary evidence: only selector and BM25 were tested, and the LLM judge was not calibrated against human inter-rater agreement.Source: Table 7 · p. 23, §11.1 · p. 23

Results

  • The selector strictly Pareto-dominates both BM25 conditions, with higher pass rate at lower input-token cost in the 30-query stale-version attack.The comparison is reported for three retrieval conditions on an intentionally adversarial suite.Source: Table 8 · p. 24, Discussion · p. 25, Figure 3 · p. 25

Two distinct failure modes for BM25

  • The stale-version experiment demonstrates both archived-version poisoning and a retrieval miss when similarity-based methods return documents without the requested information.In the poisoning example, BM25 leaky returns an archived API schema and produces a confident but failing answer; in the retrieval-miss example, both BM25 conditions return documents lacking the requested incident definition.Source: Two distinct failure modes for BM25 · pp. 24–25

Discussion

  • The findings are preliminary: the stale-version suite is adversarial and synthesized, uses a single uncalibrated LLM judge, and does not test dense retrieval; the determinism corpus is structured and its full experiment grid remains in progress.The authors describe these results as demonstrations of failure modes, not benchmarks of relative quality across realistic enterprise workloads.Source: §11.1 · p. 23, Discussion · pp. 25, 27

Setup

  • The determinism experiment used 50 queries, 20 repetitions per query and method, and three retrieval methods: selector, BM25, and dense + HNSW.The synthesized corpus replicated ten document templates across 106 service variants; HNSW indices were rebuilt with shuffled insertion order every five repetitions.Source: Setup · p. 26

11.3 Determinism of Retrieval

  • On the 1,060-document corpus, selector and BM25 were perfectly deterministic on every query; dense + HNSW was non-deterministic on 40 of 50 queries (80%), with worst-query overlap of 21.0%.The reported mean Jaccard for dense + HNSW was 0.611.Source: Table 9 · p. 26, Figure 4 · p. 27, Discussion · p. 27

Discussion

  • Deterministic selection is presented as a precondition for reconstructing an agent’s knowledge basis during audit, replay, incident investigation, or dispute resolution.The paper argues that non-deterministic retrieval cannot reliably reproduce the inputs behind a prior output.Source: Discussion · p. 27

12 Discussion

The discussion sets boundaries on ContextNest’s guarantees, reports partial results alongside a broader experimental program, and identifies specification extensions. Its limitations distinguish format-level guarantees from capabilities that require a platform or separate retrieval and identity systems.

12.1 Limitations

  • The format guarantees published-versus-draft status, while role-based stewardship depends on richer clients; local-first vaults also leave collaboration, real-time editing, and conflict resolution to a platform layer.A minimal disk client sees only publication status, and multi-user capabilities are not defined by the specification.Source: §12.1 · p. 28
  • Version attribution records one principal per document version, not paragraph-level co-authorship; piecewise attribution is proposed for a future specification revision.The interim convention makes the frontmatter author the principal of record, with secondary contributions recorded in the document at the author’s discretion.Source: §12.1 · pp. 28–29
  • Semantic retrieval is delegated to a configured back end rather than built into the specification, keeping governance independent of retrieval algorithms.The delegated surface can connect to a RAG pipeline, hybrid index, or other conforming retriever.Source: §12.1 · p. 29
  • Hash-chain verification detects tampering retrospectively but does not prevent it, including when a write-capable actor can modify both content and hashes.The chain provides evidence of tampering through broken links.Source: §12.1 · p. 29
  • The specification governs consumed knowledge, not agent identity; its request trace does not attest identity outside the local trust domain.Cryptographic identity, owner attestation, and revocation are deferred to a companion specification.Source: §12.1 · p. 29

12.2 Comparison with Existing Approaches

  • Table 11 compares context-governance properties across approaches, with RAG covering both sparse and dense retrieval pipelines.The supplied caption does not provide the table’s cell values or comparisons.Source: Table 11 · p. 29

12.3 Experimental Program

  • In the partial E1/E2 experiments, governed selection is tested for token cost and answer quality, while selectors and BM25 have Jaccard 1.0 and dense+HNSW is non-deterministic on 80% of queries.For dense+HNSW, mean Jaccard is 0.611 and worst-case Jaccard is 0.210; the 1,060-document, 50-query run uses 20 repetitions per query and method.Source: §12.3 · p. 30
  • The remaining program schedules tamper-detection, content-drift, and adversarial-poisoning studies, with the full E5 attack suite still pending.E3 expects 100% detection for attack patterns (a)–(e) by construction; E4 tests approved-version answers as documents change, while the full E5 includes six attack patterns and three retrieval conditions.Source: §12.3 · p. 30

13 Conclusion

The conclusion presents ContextNest as a verifiable knowledge-governance layer beneath retrieval and reports early results on stale-version attacks. It frames this infrastructure as relevant to trustworthy autonomy while limiting its scope to one component of a broader system.

13 Conclusion

  • On a controlled stale-version attack, governed selection strictly Pareto-dominates BM25 sparse retrieval, with higher answer-quality pass rates at about one-third the input-token cost.The conclusion also reports stale-version poisoning and retrieval miss as two BM25 failure modes in the same suite.Source: §13 · p. 32
  • ContextNest combines typed documents, deterministic selection, cryptographic integrity, temporal checkpoints, and injection tracing in an open specification for AI-agent knowledge governance.The specification is layered, from editable Markdown files with YAML frontmatter to hash-chained versioning, point-in-time graph reconstruction, federation, and audit trails.Source: §13 · p. 32
  • The conclusion frames governed knowledge as a safety and compliance requirement for increasingly autonomous enterprise agents, and identifies ContextNest as one component of the needed infrastructure.It argues that trustworthy autonomy requires verifiable knowledge supply chains composed with model and tool advances.Source: §13 · p. 32

Author Contributions1

The author-contribution statement assigns work across specification design, implementation, experiments, framing, and review. It also distinguishes scholarly contribution from intellectual-property ownership.

Author Contributions1

  • M. Sulpovar conceived ContextNest, designed most of the specification, maintains the engine, CLI, and MCP server, and designed and ran the reported experiments.The addressable URI scheme was co-designed with Q. Kanchwala.Source: Author Contributions1 · p. 32
  • The authors state that authorship does not determine intellectual-property ownership, and that the specification and reference implementation belong to PromptOwl, LLC.The statement identifies the work as the property of PromptOwl, LLC.Source: Author Contributions1 · p. 32
  • B. R. Konsynski contributed the revised introduction, intellectual lineage, and other framing; Q. Kanchwala contributed URI and hash-chain implementation and selector development; G. Goodhart contributed framing and the staged source-node lifecycle specification.The statement also describes review contributions by the authors.Source: Author Contributions1 · p. 33

Disclosure

The disclosure identifies the ownership and licensing of the ContextNest materials and reports the authors’ financial interests and affiliations.

Disclosure

  • PromptOwl, LLC owns the specification, reference packages, harness, fixtures, and query suites, which are released under the licenses indicated in the paper; M. Sulpovar has a financial interest in the company.The other three authors report no financial interest in PromptOwl, LLC; Q. Kanchwala and G. Goodhart state that they participate in their individual capacities, outside their employers’ work-for-hire arrangements.Source: Disclosure · p. 33
Loading 2607.02116v2…