AKF: portable knowledge with evidence

AKF means Agentic Knowledge Format. Its revolution is making an agent's curated knowledge a readable, verifiable artifact you can keep and move between models, providers and machines, together with its provenance and selected supporting evidence. A new conversation can begin from established knowledge instead of asking you to reconstruct it from old chats.

JARVIS supplies the Mnemos reference owner: it authenticates snapshots, applies local policy and governs publication. PRISM's prism-mem delivers bounded, cited knowledge to your selected agent. The format, owner and adapter have different jobs; they compose without a second writable memory engine.

What travels with the knowledge

Part What you can inspect
Markdown pages The conclusion, procedure or architectural decision in readable text
KDL sidecars Page identity, revision, provenance, authority and disclosure metadata
Declared sources and selected evidence What supports a claim, with declared dependencies retained
Retained history Earlier revisions and what superseded them
Manifest and signatures Exact payload membership and bytes authenticated against trusted keys

The bundle is readable without a database. Authenticated retrieval needs a compatible owner and independently trusted local policy, keys and manifest pin. Hashes detect changed bytes; a trusted signature authenticates the signed snapshot. Neither proves that a statement is true, current, or complete.

A worked transfer: keep the answer and its evidence

This lifecycle illustration assumes an existing valid signed bundle and independently trusted recipient policy; it is not a from-zero bundle-authoring tutorial.

Imagine a project decision: "Use a single writer for the operational store." The curated page explains why, cites its source revision and selected test report, and declares the supporting evidence in the bundle. This is an illustrative decision, not a benchmark result.

Source observations and selected evidence
  → curated Markdown + KDL provenance
  → validated candidate → ASM-authorized signed publication
  → export under source policy → import under destination policy
  → authenticated, bounded packet → another agent session
  1. Curate a reusable conclusion; keep raw conversations and live task state in their operational owner. Include the evidence needed to interpret the claim.
  2. Validate the candidate and publish through ASM, the Agentic State Machine, with the required authority and approvals bound to that exact candidate.
  3. Transfer the signed bundle under explicit export/import grants. The recipient independently configures trusted keys, digest, project and disclosure scope.
  4. Retrieve through mnemos knowledge get or prism-mem knowledge get, using the documented JSON envelope. Inspect authentication: "verified", the bundle/page revisions, manifest digest, citations and omissions.
  5. Bind startup explicitly if desired. A configured provider hook still needs provider trust and an actual fresh-session delivery check.

Copying a bundle grants no publication or execution rights. A recipient can read an authorized snapshot without access to the source chat database. It must still recheck live repository state before acting on an old conclusion. See the native owner guide for the policy, JSON wire, transfer operations, byte limits and refusal cases.

The portability evidence

The signed real-owner acceptance fixture exports a revision with source evidence/history, removes the original store and configuration, and retrieves the answer using recipient-only policy. It also exercises wrong-project denial, missing/revoked trust, incorrect manifest pins and payload tampering. This is a concrete portability check; it does not establish the truth of every curated claim or universal interoperability with every agent.

Read the public process acceptance fixture and its signed fixture construction. This page describes existing source evidence, not a new benchmark run.

How determinism works

A model can propose a plan or a knowledge candidate. Explicit schemas, fixed rules, policy decisions and recorded workflow steps govern what happens next. The doctrine gate is a concrete implemented example that makes no model call:

Operator selects an inspected baseline
  → CAPTURE fresh repository guidance
  → COMPARE captured evidence using compatible rule/implementation identities
  → ASSERT complete, comparable evidence with no added error findings
  → HALT and retain the gate result, receipts and audit records
Situation Defined behavior
Same captured bytes and evaluation identity Repeatable rule evaluation; no model sampling
Fresh gate invocation New observation and IDs; changed files can change the verdict
New error versus the selected baseline Gate assertion fails
Incomplete or incompatible evidence Cannot qualify as a passing gate
Replaying a completed gate Returns its recorded historical result under current admission
Recovering an interrupted gate Preserves original intent; an unresolved operation stops rather than being blindly retried

Determinism here means a specified evaluation and control path over identified inputs. It does not mean deterministic model reasoning, identical timestamps or IDs, or identical external tool effects. A passed gate means no added errors against its accepted baseline; existing errors and warnings can remain. It is not a proof that the repository is safe or that its instructions are correct.

AKF applies the same discipline at the knowledge boundary: schema, manifest, trusted signatures, disclosure, scope and revision checks before delivery; ASM requires authority for publication. Knowledge content remains reference material and cannot override runtime policy.

Try the implemented paths

Knowledge owner and PRISM adapter are implemented; installed binaries and provider versions must expose the documented commands. JARVIS gate/recovery requires the unstable builds identified in its tutorial. Publishing this website does not promote that runtime to main, install hooks, activate a scheduler, or grant publication authority.