AKF+ASM: Curated Portable Knowledge and Governed Publication for Agents

Keywords: agent memory; knowledge portability; operational context; provenance; governed publication; structured knowledge; model independence.

1 Introduction

An agent continuing a software project needs to remember what happened in its last session, which tools are installed, and which task remains open. An agent receiving the project’s knowledge on another machine needs its design rationale, procedures, definitions, and supporting evidence. These requests overlap, but answering them from the same undifferentiated archive creates an avoidable coupling between transferable knowledge and the life of the originating agent.

For example, a debugging conversation may contain abandoned hypotheses, command output, credentials accidentally included in a trace, and a final explanation of a storage failure. The explanation can be useful knowledge. The transcript is valuable operational evidence. Exporting the explanation does not require exporting every turn, and retaining every turn does not make each assertion an established fact. Conversely, a summary cannot justify a claim that all the information in the original conversation has been preserved.

This paper defines a boundary between these responsibilities. AKF stores curated knowledge and the selected support required to interpret it. An agent’s operational memory stores conversations, observations, current capabilities, work references, and execution history. ASM governs publication from either human or automated proposals into AKF. Harness interfaces provide agents with explicitly labeled views of knowledge and current context. The design does not require a particular model provider, retrieval algorithm, or external memory service.

For agents, the intended benefit is reusable knowledge that can survive changes of model, provider, or execution environment. For harnesses, AKF offers a common contract for knowledge ingestion, retrieval, governed publication, and export. A replacement harness can consume the same declared knowledge without inheriting the previous runtime’s session database or execution permissions. These are architectural benefits to evaluate, not measured performance improvements.

The central distinction is purpose rather than age. A transcript can be retained indefinitely while remaining operational. A new design decision can be published as knowledge immediately after its approval requirements are met. Likewise, a procedure can be durable knowledge while its installed implementation, current version, and execution permission remain operational facts. Calling the two domains simply “long-term” and “short-term” memory obscures this distinction.

The contribution is a format and publication contract that makes this separation portable and testable. It comprises four connected elements:

1. Explicit knowledge and operational-context domains, linked by selected, attributable promotion rather than automatic transcript accumulation.

2. Plain-file knowledge bundles with stable identities, structured data, retained revisions, and declared export dependencies.

3. A publication state machine that separates disclosure, authorization, and evidential support, with candidate-bound approval and recoverable publication.

4. Integrity, migration, and conformance requirements that distinguish a readable bundle from an authorized publisher or a verified restoration.

These are design contributions rather than empirical findings. The paper explains AKF standard 2.0.0 and supersedes the architectural account in earlier paper revisions. Section 9 reports the narrower status supported by source inspection of one agent-system prototype. All examples are illustrative; no example is presented as a completed deployment or an evaluation result.

2 System model and domain boundary

2.1 Knowledge, context, and originating authority

We use knowledge artifact to mean a deliberately published object intended for reuse, not a guarantee that every statement it contains is true. Artifacts can preserve a disputed finding, an attributed claim, or a superseded decision, provided their interpretation is explicit. Operational context is material maintained to understand or continue activity in an environment. Curation decides which material merits publication, with what scope and evidence.

Table 1 illustrates the distinction. An item’s location is not inferred from its age, filename, or frequency of retrieval. Repeatedly copying an assistant’s unsupported assertion does not supply independent confirmation. A historical observation also does not establish the present condition of the system it describes.

A remembered issue remains an observation of the issue system’s record. The operational memory service does not create a second independently editable issue. The same rule applies to review findings, calendars, and service inventories. Provenance must retain the source identity and revision; freshness must be evaluated against the owning system before acting on current-state claims. A curated historical account may cite these records without taking over their operational ownership.

2.2 Components and interfaces

An agent is the process that pursues a task, consumes knowledge, and may propose new knowledge. A harness is the surrounding runtime that provides model and tool interfaces, context assembly, execution controls, and audit. These are functional roles: one application may implement both, and neither is a prescribed product or deployment topology.

Figure 1 separates capture from publication. Operational memory maintains continuity for agents; harness interfaces connect them to that memory and to curated knowledge. AKF defines the interchange format, while ASM defines publication requirements enforced under trusted operator policy. A harness may host a conforming publisher or invoke a separate publication service. A CLI may expose memory and knowledge without starting a full agent loop. Conformance depends on the contract, not on which component hosts the service.

The operational interface should support authorized capture, scoped search, source retrieval, bounded working-context assembly, and separate operational export. The knowledge interface should support proposal, inspection, validation, approval, publication, retrieval, and export. These are capability requirements, not claims that a new memory CLI or v2 publication commands already exist.

Search results carry source IDs, revision IDs, scope, observation time, and their domain. An adapter must disclose unavailable evidence and truncation. A bounded context packet can combine a current task reference with a published architecture page; the packet remains a timestamped operational projection. Its generation does not create a new canonical AKF revision.

3 Portable knowledge representation

3.1 Directory structure and compatibility

A core AKF v2 bundle contains plain UTF-8 Markdown, a KDL 2.0 bundle descriptor, adjacent KDL page metadata, and declared supporting files. KDL serves human authoring; JSON serves agent interchange. Topic folders and their _index.md pages provide navigable structure. The reader does not need the originating agent or harness, an embedding model, a database server, or a special mount. Compression is an optional transport choice. Zstandard is one suitable lossless encoding (Collet and Kucherawy 2021); it does not define the knowledge lifecycle or establish random-access mounting support.

project-knowledge/
  _bundle.kdl
  CONTEXT-RULE.md
  _index.md
  _changelog.md
  _sources.jsonl
  architecture/
    _index.md
    memory-boundary.md
    memory-boundary.kdl
  procedures/
    _index.md
    restore-workspace.md
    restore-workspace.kdl
  evidence/
    _index.md
    observations.md
    observations.kdl
    observations.jsonl
  sources/
    boundary-decision.md
  _history/
    index.jsonl
  _integrity/
    manifest.json
    signatures/

The _bundle.kdl descriptor has one bundle root node with child fields standard "AKF", standard_version "2.0.0", a bundle ID and revision, its parent revision, creation and update times, title, disclosure scope, domains, required profiles, export kind, and history scope. Bundle and revision IDs use [A-Za-z0-9_-]+. A root has an empty parent identifier; subsequent revisions identify the exact revision they replace. Timestamps use UTC RFC 3339 (Klyne and Newman 2002). Revisions are unique identities, not estimates of age or an ordering inferred from a wall clock.

Readers reject unsupported major versions and required profiles. An optional extension may be preserved without interpretation, but an unknown required semantic cannot be silently ignored. A filename ending in .akf establishes neither version nor conformance. V1 bundles remain labeled v1 until an explicit migration; their historical validity does not imply v2 compatibility.

Core paths use segments matching [A-Za-z0-9_.-]+. Empty, dot, parent, absolute, symbolic-link, and ASCII case-colliding paths are rejected. The restriction concerns portable paths, not Unicode text or metadata values. Reserved root names begin with an underscore. Declared evidence blobs carry relative paths, media types, byte lengths, and digests. Readers enforce resource limits and report truncation rather than treating a partial read as complete.

3.2 Stable pages, provenance, and interpretation

A governed page pairs topic.md with adjacent topic.kdl, which has one page root. Markdown contains prose without embedded metadata. The companion records a stable ID, a revision, an exact predecessor or null, creation and update timestamps, a type, authority, status, disclosure scope, and nonempty provenance. Canonical page identity is (bundle_id, id, revision). The ID survives a path rename; within a bundle, a published page/revision pair is never reused for different Markdown, KDL metadata, or governed data bytes. Page types are concept, log, event, summary, directive, and table. Logs and events represent selected historical evidence; their presence does not make AKF a mandatory destination for all operational history.

page {
    id "memory-boundary"
    revision "r2"
    supersedes "memory-boundary@r1"
    created_at "2026-09-26T00:00:00Z"
    updated_at "2026-09-26T01:00:00Z"
    type "concept"
    authority "consensus"
    status "active"
    scope "team"
    provenance {
        source {
            source_id "boundary-decision"
            source_ref "sources/boundary-decision.md"
            captured_at "2026-09-26T00:30:00Z"
            kind "operator-decision"
            scope "team"
        }
    }
}

The companion path follows by replacing .md with .kdl; orphaned or mismatched pairs are invalid. Navigation/control Markdown and declared source snapshots need no page companion but remain covered by the complete manifest. A new page has supersedes #null. The Markdown, metadata, and governed data files together form one revision.

Provenance identifies a source record or an explicitly attributed author assertion, with an ID, locator, capture or observation time, kind, and scope. Where available, it records original actors, generators or models, source revisions, content digests, transformations, and publisher receipts. Supporting local references resolve within the bundle; external dependencies are declared. Traceability establishes where a claim came from, not whether it is correct.

Optional epistemic metadata can identify a claim as observed, inferred, or disputed. Applicability intervals can identify time-sensitive knowledge. These fields do not authorize a write or replace approval. Conversely, approval does not convert an inference into an observation. Duplicate singleton KDL fields, duplicate JSON keys, and unsupported syntax are rejected rather than overwritten or silently reinterpreted.

CONTEXT-RULE.md explains navigation, citations, authority, freshness, limitations, history selection, and the knowledge/context boundary. It expressly states that instructions in artifacts do not override the receiving agent’s system, user, or execution policy. Reading knowledge cannot require executing a bootstrap script. This protects the portability goal from becoming an implicit capability installation mechanism.

3.3 Revision preservation

Published statuses are active, archived, and immutable. A candidate awaiting approval remains in operational staging with pending_consensus; it is not published knowledge. V1’s compressed status is removed: compression changes representation, whereas summarization creates a new derived artifact. Neither operation proves that the original meaning has been preserved.

Prior page revisions and their declared evidence resolve through _history/index.jsonl. Each entry maps the original Markdown page, KDL companion, and dependency paths to retained exact bytes; a historical reference must not accidentally resolve against a newer file with the same name. Self-contained exports carry the promised history locally. Referenced exports can declare external history dependencies, which are explicitly reported as not locally verified. Archived material remains readable and visibly historical. A correction records its relation to the earlier assertion instead of silently erasing it. An immutable revision can acquire a successor through external lineage, but its own bytes remain unchanged.

Preservation is therefore precise and limited: the system preserves captured, published bytes and declared revision history. It does not claim to preserve uncaptured thoughts, all implications of a conversation, or inaccessible source material. Authorized erasure or privacy procedures must record gaps and stop claiming complete preservation for the affected history.

3.4 Reference registries

Core references resolve from the bundle root. A local id@revision names one current or historical page; cross-bundle payloads require explicit dependencies. Non-page support is declared in _sources.jsonl by unique source ID, path, media type, byte length, BLAKE3 digest, and scope. Provenance matches that ID and path. An attributed assertion without a separate source instead uses source_ref "self", an actor, and the author-assertion kind; consumers label assertion-only support explicitly.

_dependencies.jsonl records an external resource’s owner, kind, URI, required status, scope, observation time, digest when available, and reason. Provenance refers to it as dependency:<id>. Citation-only hyperlinks do not imply availability or reconstruction. A required unmaterialized dependency precludes a self-contained export. Materializing it produces a newly governed revision rather than rewriting an immutable original.

Registries use one JSON object per LF-terminated line, UTF-8 without a byte-order mark; duplicate keys are invalid. The history registry records page identity, source bundle revision, original path, stored Markdown and KDL paths, and dependency path mappings. These mappings preserve exact historical bytes while making relocations unambiguous. Optional registries become required when their feature is used.

3.5 Human authoring and agent interchange

The KDL 2.0 profile (Marchán and KDL Contributors 2026) uses child nodes without property assignments or type annotations. Scalar nodes map to scalar values; positional lists map to arrays; declared repeated record groups, such as provenance sources, map to arrays of objects. #true, #false, and #null map to their JSON counterparts. Scalar/list nodes reject child blocks; root, object, and record nodes reject positional arguments. Multiplicity is checked before projection, so mixed shapes and duplicate fields cannot disappear through object assignment. Relations and namespaced extensions require profile-defined mappings. Comments are presentation; inactive slashdash nodes are not active metadata.

Agents use JSON requests, responses, and proposals under RFC 8259 (Bray 2017), with JSONL for registries and row streams. Core rejects duplicate keys, non-finite values, isolated surrogates, and ambiguous mappings. Metadata integers lie in $[-(2^{53}-1),2^{53}-1]$ without rounding. Schema-defined round trips preserve scalar types and array order. Unsupported extension mappings are reported as incomplete projections and cannot justify a lossy rewrite.

An agent page record contains bundle and revision IDs, Markdown and metadata paths, a mapped metadata object, and the Markdown body. A proposal adds the expected base revision. The owner renders and validates candidate KDL and Markdown before approval of the exact manifest. JSON equivalence does not authorize changes to signed formatting. There is one editable persisted pair; generated JSON views are read-only, never parallel metadata masters. Native JSON manifests, proposals, and registries have distinct roles.

4 ASM: authority and publication

4.1 Three independent questions

ASM separates three questions for every relevant operation: may an actor read or disclose this material; may that actor propose, approve, or publish a change; and what evidence supports the content? The first concerns disclosure, the second mutation authority, and the third epistemic quality. Combining them into a single trust score would hide materially different failure modes.

Trusted policy outside the artifact defines principals, grants, namespaces, approval thresholds, and revocations. An artifact cannot authorize changes to itself. Scope labels—private, team, or public—describe intended disclosure; authenticated enforcement is a runtime responsibility. Effective access is the intersection of restrictions on the bundle, page, source, and table column. Missing policy cannot authorize wider sharing.

Table 2 states the mutation model. Consensus policy specifies eligible principals, thresholds, independence or self-approval constraints, and expiry and revocation handling. Distinct identities count toward a threshold; multiple signatures by one identity are not multiple approvals. Autonomous publication still requires an explicit grant. Being the only writer, running at night, or reporting high model confidence supplies no authority.

A candidate approval is invalidated by a change to its payload, schema, scope, authority, or base revision. Downgrading authority is governed by the existing authority and any stronger namespace policy. Archiving is also a change subject to current authority. An approved consensus revision does not permanently grant an agent the right to edit future versions. An immutable artifact is corrected by a new revision under at least the predecessor’s authority, never by modifying the sealed object.

4.2 Promotion transaction

Curation can run overnight, at session completion, or on demand. These schedules invoke the same publication protocol. A routine morning briefing belongs to operational context; a reusable finding discovered while producing it can be proposed for AKF. A successful run may publish nothing.

The proposed transaction proceeds as follows:

1. Select. Identify reusable content, the evidence necessary to interpret it, its scope, and remaining uncertainty. Leave transient context, rejected drafts, and execution traces in the operational domain.

2. Reconcile. Compare candidates with published identities and revisions. Record duplicates, contradictions, and succession without treating copied assertions as independent evidence.

3. Validate. Check schema, paths, provenance, disclosure, history, and the complete dependency set. Reject or diagnose invalid candidates rather than silently dropping their inconvenient parts.

4. Authorize. Bind approval to exact bytes, namespace, and expected base revision. Recheck grants and revocations at commit time.

5. Publish. Compare the current base, make one validated revision visible atomically, and record the resulting revision and receipt. A conflict requires revalidation and new approvals.

One logical publication coordinator controls each namespace using a lock, transaction, or compare-and-swap protocol. Multiple collectors and proposers may operate concurrently. The required property is a serialized publication decision, not a single process that must manually perform every capture.

Let $B$ be the expected base revision and $C$ the validated candidate. A commit is admissible only when the visible head still equals $B$ and current policy authorizes $C$. Readers must observe either the previous complete revision or the new complete revision. This visibility invariant alone does not prove crash durability; an implementation must specify persistence ordering, recovery, and interruption behavior. Advancing an ingestion checkpoint before durable publication would otherwise lose a candidate on retry.

Successful promotion does not consume or delete the operational source. Operational retention has its own explicit policy. Uncertain material may be preserved as an attributed or disputed claim when useful, but must not be promoted as an established fact merely to empty a curation queue.

5 Integrity and trust

5.1 Canonical bundle manifest

A v2 publication contains _integrity/manifest.json. It lists every regular bundle file except itself, detached signatures, and optional _cache/ contents. Cache bytes cannot be necessary to interpret knowledge. Other paths under _integrity/ are invalid in the core representation.

The manifest has exactly five fields: format, bundle_id, bundle_revision, parent_revision, and files. The format is AKF-MANIFEST-V2; IDs agree with _bundle.kdl, and a root has an empty parent ID. The following pretty-printed object illustrates the shape only: its empty file array is not a valid manifest for a populated bundle.

{
  "format": "AKF-MANIFEST-V2",
  "bundle_id": "project-knowledge",
  "bundle_revision": "r000002",
  "parent_revision": "r000001",
  "files": []
}

Each file entry contains exactly a unique relative path, integer bytes in $[0,2^{53}-1]$, and a lowercase 64-character blake3 digest. The file array is sorted by unsigned UTF-8 path bytes. RFC 8785 JSON Canonicalization Scheme (JCS) (Rundgren, Jordan, and Erdtman 2020) determines object-key ordering and exact serialization: UTF-8 without a byte-order mark or trailing newline. Verification rejects bytes differing from canonical serialization. JCS object sorting and AKF’s file-array sorting are separate requirements.

Digests cover exact Markdown, KDL metadata, table data, history, and selected evidence bytes using BLAKE3 (O’Connor et al. 2020). KDL formatting is not normalized after approval. Body-only hashing would miss changed authority, scope, schema, or evidence. Validation checks complete membership, lengths, and digests; an unlisted file is an integrity error inside an asserted exact snapshot.

5.2 Signatures and authorization

Detached signatures use Ed25519 as specified by RFC 8032 (Josefsson and Liusvaara 2017). If $M$ denotes the exact manifest bytes, the signed message is $$m = \operatorname{UTF8}(\texttt{AKF-SIGNED-MANIFEST-V2\textbackslash n})\;\Vert\; M, \qquad \sigma = \operatorname{Ed25519.Sign}(sk,m),$$ where the displayed \n denotes one LF byte, not two literal characters. The explicit domain prefix separates this signed object from other uses of the same key. Ed25519 is applied to $m$; the construction does not imply Ed25519ph or an unspecified prehash variant.

A signature file is JSON with exactly algorithm, key_id, principal_id, and signature. The algorithm is Ed25519; the signature is RFC 4648 base64 (Josefsson 2006) of the 64-byte signature. Trusted policy resolves the key-to-principal binding. A claimed principal in the JSON envelope is not proof of identity, and a public key supplied by the same untrusted bundle is not automatically an authorized signer. Envelopes are regular <key_id>.json files directly in the signatures directory; duplicate JSON keys, unknown fields, and invalid base64 are rejected.

Every new snapshot satisfies the authority of all current and retained local historical pages, together with namespace policy. Carrying a sovereign or consensus page forward therefore still requires its authorized signature set on the new manifest, even if the only edit concerns an autonomous page. Any snapshot containing immutable content requires an authorized publisher signature. Core v2 does not assume an optimization that substitutes historical proofs for this re-attestation. A wholly autonomous snapshot without immutable content may be unsigned only when namespace policy permits; it is then integrity-checked but unauthenticated. Historical authorization and permission to act now remain distinct questions; external receipts and policy snapshots retain their context.

Neither hashes nor signatures establish truth. Hashes detect differences relative to trusted digests; signatures attest bytes under a key and trust policy. They do not prevent deletion by a privileged filesystem writer, establish the freshness of the currently presented revision, or conceal its contents. A consumer needing rollback protection must pin a trusted latest revision or verify an authenticated revision ledger. Access control, backups, key management, and storage durability remain explicit operational responsibilities.

6 Structured knowledge and selected evidence

AKF’s structured-knowledge layer, ARK, keeps tabular data distinct from prose summaries. A table page declares a schema and exactly one of a local CSV/JSONL sidecar or an optional connector profile. Core self-contained bundles use local data. The schema specifies each column’s name, type, semantic meaning, and scope; it also specifies nullability, primary key, row count, and encoding. Measured numeric values and durations have units; counts explicitly identify their dimensionless interpretation.

The core types are text, integer, real, boolean, timestamp, duration, and reference. Reference columns identify the target table and key. Derived columns declare inputs and transformation. Validation checks key uniqueness, types, row counts, references, and required units. A glossary can explain domain terms that names alone do not resolve. These checks support interpretation; they do not prove that the recorded observations are accurate.

Serialization is explicit. Core schemas have one non-null unique primary-key column, and every row contains exactly the declared columns. JSONL uses native JSON scalar types, exact integers in $[-(2^{53}-1),2^{53}-1]$, finite numeric values, and null for nullable fields. Larger exact integers require a declared string-based profile; silent rounding is forbidden. CSV remains a declared dataset encoding, not an agent interface, and specifies its delimiter, header, and reserved null token; quoted cells escape double quotes by doubling them. Empty text and null remain distinct. Reference columns name an exact target table revision and key, with matching scalar encoding. Schema or encoding changes require a fresh page revision even when the prose is unchanged.

The table page, schema, sidecar, and relevant glossary form one governed revision unit. Editing a data file is a knowledge change even when the Markdown remains unchanged. A schema change affecting referenced tables requires consensus authority and validation of the dependent closure. A column’s scope cannot be widened by copying its rows into a more public page.

Connector profiles can describe live external data without placing credentials inside AKF. Such a referenced bundle declares its dependency, observation time, and unavailable rows. It cannot claim independent reconstruction of changing external data. To become self-contained, an export materializes an authorized snapshot and binds its bytes to the exported revision. Query engines and derived graphs may support joins or navigation, but their existence does not replace the underlying table semantics and data.

Review evidence illustrates selective promotion. A review system can own the complete history of runs, findings, comments, treatments, and execution results; an operational memory service can index that history. A published lesson about a recurring failure can carry selected findings and the exact observations needed to assess it. That slice retains original identities, uncertainty, and source revisions. Bulk capture does not become a curated wiki simply because its records have columns or because an exporter produced them.

7 Retrieval, export, and migration

7.1 Retrieval without ownership transfer

AKF permits lexical search, vectors, tree navigation, and graph indexes as derived retrieval mechanisms. No particular index is the only surviving representation of knowledge. An index entry points back to the canonical bundle, page, and revision; regenerating the index must not alter their authority. LLM-generated retrieval summaries remain projections unless separately published through ASM.

Provider adapters preserve the distinction between knowledge and operational context even when a user asks one combined question. “Why was this design chosen?” can retrieve a published decision and its evidence. “Is the service running now?” requires a sufficiently fresh operational observation. An answer combining them must not let the authority of the design document substitute for verification of the current service state.

CLI and API operations cross implementation boundaries explicitly. A harness may implement conforming validation and publication itself or invoke a separate service. Provider adapters must preserve the same contract and must not bypass ASM through direct writes to published knowledge. Basic human inspection remains possible with a text editor or search tool. Manual edits become publication proposals; the fact that files are editable does not exempt them from validation.

7.2 Export closure and derivatives

An export declares audience, knowledge selection, source revision, and history scope before materialization. The default selection excludes operational stores, credentials, sessions, task databases, model caches, and complete chat or review archives. An authorized operational checkpoint can accompany the export, but remains separately scoped and labeled.

Let $S$ be the selected knowledge revisions and let $D(S)$ contain their required schemas, evidence, sidecars, and interpretation dependencies. For a self-contained export, the payload includes the transitive closure of these dependencies and the history promised by the export. Conventional external citations can remain citations when they are not required payloads. A missing required source cannot be hidden behind a link to the originating machine.

AKF therefore distinguishes self-contained and referenced exports. A referenced export discloses external dependencies and omissions; a self-contained export must meet its reconstruction claim without the original runtime. Neither mode permits leaking private support to satisfy closure. If the audience cannot receive a dependency, the exporter either creates a valid, explicitly narrower derivative or refuses that export.

History is declared as all-published or selected. Selected history enumerates omitted revision IDs and reasons. A lineage-only predecessor may be explicitly omitted and reported unavailable without invalidating a self-contained export of the declared selection; required evidence and table references still need their full dependency closure. Removing knowledge, redacting fields, or narrowing history creates a new bundle ID and integrity manifest with a derived_from reference. The result is not represented as an unchanged complete copy. The descriptor records the source bundle, revision, and manifest digest; _derivation.jsonl maps every copied or transformed page back to its original identity and separate Markdown and KDL digests. Unchanged copies retain their source identity in this map while acquiring the derivative bundle namespace. Changed page, schema, or governed sidecar bytes require a fresh page revision. A derivative cannot weaken source authority. Table derivatives preserve remaining key and reference validity and disclose removed columns.

Exports stage in a fresh destination and validate before becoming visible. Accidental overwrite is refused. An explicitly authorized replacement swaps one complete validated snapshot for another; overlay copying can leave stale files that were never part of the new revision. Imports quarantine untrusted input and check paths, versions, and profiles without inheriting embedded claims of local execution authority.

A restoration drill measures a stronger property than successful file transfer: export, import in an isolated environment, validate, and answer declared knowledge queries from the restored artifact alone. The result applies to captured bytes and promised history. It cannot establish completeness of information that was never recorded.

7.3 Migration from the earlier all-memory layout

Earlier AKF material used 0-raw, 1-wiki, 2-digest, and identity, project, and task records as one operational vocabulary. V2 does not require these layers or classify their contents by directory name. This is a breaking semantic change rather than a cosmetic rename.

Migration inventories and hashes the original bundle, preserves it, and builds a separate staged destination. Each artifact is classified as curated knowledge, selected support, operational context, derived cache, or unresolved. Operational material is copied to a separately selected destination only under its owner’s scope and retention policy. The migration report records source-to-destination identities, unresolved items, omissions, and history mappings.

Legacy summaries and their sources need explicit treatment: a compressed status is not evidence that source detail survived. The selected knowledge receives v2 metadata, lineage, indexes, schemas, and dependency closure. Migration extracts plain Markdown and explicitly converts legacy metadata into paired KDL records and _bundle.kdl. New serialization requires fresh manifests and approvals; old signatures do not attest the new bytes. Validation and an isolated restoration drill precede acceptance. The migration must not rewrite live stores in place or infer v2 conformance from historical v1 test results.

8 Threat model and limitations

The design assumes that source material and model-generated candidates can be untrusted. Attackers may submit prompt-injection text, forge actor names in metadata, replace files or sidecars, replay old valid revisions, or exploit concurrent publication. Accidental failures include partial exports, stale source observations, duplicate ingestion, interrupted writes, and approval of a candidate whose contents subsequently change.

Trusted components are the policy configuration and its principal bindings, the publication coordinator, the verifier, and the enforcement boundary protecting their state. A filesystem administrator who can rewrite both the trusted policy and executable verifier is outside the integrity guarantee. Key compromise, revocation distribution, storage availability, and authenticated latest-revision discovery need operational controls; the file format does not solve them alone.

Candidate-bound approval and base comparison address approval reuse and lost updates when correctly implemented. Complete manifests expose metadata, evidence, and sidecar substitutions. Scope and dependency checks constrain accidental cross-domain disclosure. Treating all artifact text as data preserves the receiving agent’s policy boundary against instructions contained in recalled content. Each statement describes a required mechanism, not a proof that the current prototype has implemented it correctly.

Semantic risks remain. A well-signed page can be wrong, a selected excerpt can omit relevant context, and a curator can repeatedly amplify a mistaken interpretation. Provenance and retained history make correction auditable; they cannot automate truth determination. Source independence, conflicting evidence, applicability, and uncertainty require explicit review criteria. A clean presentation must not hide disagreement or turn “not retrieved” into “does not exist.”

Retention also has costs. Operational continuity can expose sensitive conversations long after they were useful. Knowledge portability can broaden disclosure beyond the context in which evidence was collected. The separation makes selective sharing possible, but it does not determine the correct retention period or justify collection. Operators must configure scope, capture consent where applicable, and separately authorized deletion procedures.

9 Implementation status and evaluation protocol

9.1 What current source inspection supports

The inspected agent-system prototype contains a partial earlier AKF implementation, with legacy metadata parsing, bundle scaffolding, selected validation, an authority helper, CLI operations, transfer code, and approval-record integration. These establish implementation starting points, not v2 conformance. Table 3 records specific limitations observed on September 26, 2026.

In particular, source inspection does not support earlier broad claims of signed lifecycle transitions, complete approval enforcement, or an implemented nightly knowledge compiler. This revision reports no passing test count, measured recall, latency, throughput, security completeness, or production readiness. Implementing v2 requires dedicated changes and evidence against its own acceptance criteria.

9.2 Role-specific conformance

A reader, publisher, exporter, and optional profile claim conformance separately. A reader can validate syntax and integrity without being authorized to publish. Without trusted policy, it must report authority as unauthenticated rather than adopting the artifact’s self-description. A publisher cannot establish conformance merely by successfully parsing a bundle.

Table 4 defines a prospective evaluation protocol. Each case requires fixed fixtures, exact source revisions, commands, outputs, and stated runtime versions. Tests should include valid cases and minimal adversarial mutations, so a rejection demonstrates the relevant boundary rather than an unrelated parse failure. The table describes work to perform, not results.

9.3 Usefulness beyond conformance

Conformance alone does not show that curation improves an agent’s work. A separate study should compare a scoped operational archive, curated knowledge alone, and the combined labeled interface on the same authorized corpus. Queries should include exact conversation recall, current-state questions, explanation of prior decisions, procedural reuse, and contradictory updates. Each query class needs a source-grounded expected answer and an acceptable abstention condition.

Useful measurements include answer correctness, citation validity, stale-state errors, omitted qualifications, cross-scope disclosure, task success, latency, and context budget. Evaluation should preserve the same source revisions and report model, prompt, retrieval configuration, curation cost, and repeated-run variation. A claim that one design improves recall requires those measurements; a smaller export or more concise wiki is not sufficient evidence.

A restoration experiment should make the originating agent, harness, operational memory service, and provider connection unavailable, then test the selected portable knowledge through an independent reader. Conversely, a continuity experiment should change tool availability and task state to test whether operational retrieval respects freshness. Keeping these experiments separate avoids rewarding a knowledge store for remembering stale operational facts.

10 Related work

Retrieval-augmented generation. Lewis et al. combine parametric language models with retrieved non-parametric memory (Lewis et al. 2020). Retrieval answers which material to supply to a model; it does not by itself define publication rights, migration, or preservation. These responsibilities can coexist. Vector indexes can be derived AKF indexes, and operational retrieval can use dense, lexical, or hybrid methods. No incompatibility between vectors and governance is asserted here.

Open Knowledge Format. Google’s Open Knowledge Format (OKF) was introduced by Google Cloud in June 2026 as portable Markdown with metadata conventions (McVeety and Hormati 2026a). Its July 2026 v0.2 announcement adds provenance, generated and verified metadata, freshness and lifecycle vocabulary, and attested computations (McVeety and Hormati 2026b). These mechanisms address questions also relevant to AKF; it would be inaccurate to describe current OKF as lacking lifecycle or trust signals. The distinction emphasized here is AKF’s separation of operational context from published knowledge, coupled to mandatory, candidate-specific ASM publication and export requirements. This paper does not establish comparative security or usability superiority.

Tree-based retrieval. PageIndex organizes document retrieval around hierarchical structure and model-guided navigation (Zhang, Tang, and PageIndex Team 2025). Such indexes can complement AKF topic indexes and stable page references. Their retrieval behavior is independent of whether the indexed material was published under an authority policy. We cite the method as related work and report neither its benchmark scores as AKF results nor an integrated PageIndex dependency.

Cryptographic attestation. The in-toto framework makes software supply chain steps verifiable through recorded attestations (Torres-Arias et al. 2019). This motivates a useful distinction for knowledge systems: verifying who attested to which bytes differs from establishing the truth of those bytes. AKF’s manifest and signatures apply standard hash and signature mechanisms to a complete bundle; they do not reproduce in-toto’s supply chain model or establish equivalent security properties. Trusted principal policy and fresh revision discovery remain explicit requirements.

Plain-file and versioned knowledge systems. Wikis and version control already provide familiar mechanisms for human-readable documents, revision history, and collaboration. AKF does not claim that these properties are novel individually. Its proposal is a portable contract connecting selected evidence, structured knowledge, role-specific conformance, and governed publication, while preserving an independently useful operational memory domain. Empirical comparison with an ordinary versioned wiki is part of the evaluation agenda, not a result of this specification.

11 Conclusion

AKF v2 treats portable knowledge as a deliberately published collection of artifacts, selected support, and declared history. Agents obtain this knowledge through harness interfaces while operational memory separately maintains the context needed to continue work in a particular environment. The boundary is purpose and authority rather than age, and promotion does not require discarding operational history or exporting it with every knowledge transfer.

ASM supplies the publication contract: separate disclosure from mutation and truth claims, authorize exact candidates, preserve predecessors, and publish complete revisions recoverably. Plain files and explicit dependencies make the knowledge inspectable beyond the originating runtime. Agents can reuse it across environments, and harnesses can integrate it through a shared contract without depending on the survival of any particular product. The inspected prototype is partial; conformance and usefulness must be demonstrated by the stated validation and evaluation protocols. This distinction between specified behavior and demonstrated behavior is necessary for the portability claim itself to be credible.

References