Open Knowledge Format Mapping

What makes Open Knowledge Format useful here?

It validates the wiki as an agent-readable knowledge bundle: markdown files, YAML frontmatter, stable paths, normal links, and change logs.

The local rule is stricter than OKF. OKF defines the portable minimum. Dreamineering standards define the working contract for this wiki.

Changes my mind: a generated graph finds no stronger retrieval path after typed Context links are added.

For agent-facing knowledge, the working contract starts at Agent Knowledge Contract. /playbook/agents is the OKF-readable source layer that external AI agents can quote, link, export, and improve.

Portable context is not enough. An agent also needs Delegation: the decision-rights layer that says when it may act alone, ask first, escalate, or refuse.

What OKF Adds

Google Cloud introduced Open Knowledge Format on June 13, 2026 as an open specification for portable AI context. The core shape is simple:

• a directory of markdown files
• one concept per file
• YAML frontmatter for queryable fields
• normal markdown links as graph edges
• optional index.md files for progressive disclosure
• optional log.md files for chronological history

The article says OKF v0.1 is minimally opinionated: every concept needs a type field, while producers choose their own content model. That makes OKF a lowest-common-denominator exchange format, not a full writing standard.

Local Mapping

OKF convention	Dreamineering standard	Local rule
type frontmatter	Page Types	type means page job: hub, concept, playbook, industry-performance, and so on.
Markdown file	Documentation Writing Standard	A page must stand alone without private project context.
File path as identity	Naming Standards	Route and filename are stable semantic handles.
index.md hierarchy	Index Page Standard and Hub Index Template	Index pages route before they teach.
YAML frontmatter	Wiki Schema	Frontmatter is queryable map data, not decoration.
Markdown links	Information Architecture Standard	Links should carry scent and typed relationship intent.
log.md history	Wiki-log pattern	Public pages teach current truth; the private wiki log records schema evolution.

Local Deviations

Dreamineering follows OKF's portable shape, but it changes three operating details on purpose.

• No per-directory log.md. The public bundle does not carry local process history beside each page. Schema and routing changes close into private controller receipts under .AGENCY/.NAVIGATION/CONTROLLER-RECEIPTS/.
• Private generated global index. The repo keeps a generated CONTENT-MAP and boot index as local agent discovery surfaces. They are a local extension beyond OKF, not public teaching pages.
• Hub index.mdx pages route readers. Public folder indexes are the progressive-disclosure layer. They help people and agents choose the right child page before reading deeply.

Meaning Graph Extension

Dreamineering extends OKF with a meaning graph. The graph keeps the portable markdown shape, then adds enough local structure for agents to rank, traverse, and prove ideas.

OKF page node -> DDL concept node -> typed edge -> proof signal -> centrality -> belief mass

The five-part stack is:

Layer	Job
Node	A page route or DDL concept that can be addressed by agents.
Term	A DDL name with a stable home route in /playbook/agents/ source data.
Edge	A typed Context link that says how one idea relates to another.
Proof	A proved-by edge or proof-state signal that keeps claim strength tied to evidence.
Weight	A derived centrality score from the graph. Editors do not hand-write PageRank scores into source files.

The local metadata envelope is:

• type and template name the page job and writing pattern.
• page_job names the exact reader decision or operating action the page supports.
• pillar names the 5P role when a page belongs to a business or industry function.
• loop_phase places the page in intention, action, or evolution.
• level says whether the page is entry, working, or deep.
• DDL home binds canonical terms to playbook routes.
• typed_edges come from Context bullets.
• proof_state is claim-state evidence when a page has it.
• centrality is derived by the graph generator only.

Reality maps use type: map-of-reality and generator_skill: drmg-map-reality. This is the local OKF extension for Markdown files named *REALITY*. It is the first part of the Dreamineering method: know the truth of what you have to deal with before imagining the Dream or choosing the Bridge. The page must expose true current state: existing artifacts, assets, code, diagrams, proof, and gaps.

Business and industry pillar pages use job-specific type values so the graph can read the Tight Five without opening the body:

Function	Type family	Required helper fields
Industry principles, performance, platform, process, players	industry-*	pillar, page_job
Business principles, performance, platform, process, players	business-*	pillar, page_job

Examples:

type: industry-performance
pillar: performance
page_job: "Gauge the industry with KPI baselines, benchmark thresholds, and good-vs-bad signs."

type: business-platform
pillar: platform
page_job: "Map the capability's assets, tools, standards, and operating infrastructure."

Do not use domain-map when the page job is one 5P pillar. domain-map is for the broader territory map.

Use this Context pattern for graph edges:

- **depends-on** [DDL Nomenclature](/playbook/language/symbolic/ddl-nomenclature) — terms need a canonical meaning before they can become graph nodes.

The live relationship labels are:

• depends-on — the source cannot be understood or trusted without the target.
• pairs-with — the ideas naturally co-activate.
• applies-to — the source concept is used in the target domain or method.
• proved-by — the target supplies proof for the source.
• risk-governed-by — the target bounds risk, authority, or misuse.

Normal markdown links still count as weak edges. Typed Context links carry more graph weight. proved-by carries the most weight, then depends-on, applies-to, pairs-with, and normal links. risk-governed-by is a governance edge with proof-like importance.

Agent Knowledge Contract

Agent-facing knowledge has one extra rule: a page must say whether it is source, projection, discovery, execution, or proof.

Layer	Home	Job
Source	/playbook/agents/	OKF-readable markdown that names current language, capability, evidence, receipts, services, and loops.
Discovery	agent.json, llms.txt, llms-full.txt	Machine-readable entry points for external agents.
Delegation	Delegation	Decision rights that bound act-alone, ask-first, escalation, and refusal cases.
Execution	Skills, hooks, and Stackmates drmg	Procedures and build loops that make the contract operational. Playbook search loads existing knowledge, kb-enrich writes back universal lessons, and kb-edit-playbook conducts page edits.
Proof	receipts, capability mirrors, Stackmates evidence	Closed-loop evidence of what is REALITY, DREAM, or CONSUMED.

The recovered /playbook/agents source layer now carries these OKF-readable children:

• Agent Operating Model — identity, capability contracts, machine-readable surfaces, and trust signals.
• DDL Nomenclature — canonical human-readable agent language.
• Dreamineering Symbols — DML and A&ID wire-format notation.
• Language Crosswalk — term-to-symbol binding across language densities.
• Actions And Consequences — profile-led action design for agent-facing artifacts.
• MCP Toolkit — connector reality, desired posture, classification, and human-owned remediation.
• Agent Funnel — discovery-to-receipt path for agent consumers.

Design Decision

Treat OKF as an interoperability benchmark, not the source of truth.

OKF is the port, not the ship. It makes knowledge portable. It does not decide whether a claim is true, current, safe, useful, or wise. A working memory system needs a stricter local profile for evidence, decisions, outcomes, lessons, visibility, purpose, and lifecycle.

For learning memory, keep two update modes distinct:

Memory surface	Update rule	Why
Evidence, decisions, outcomes, lessons	Append and supersede	Learning requires the historical reason and consequence.
Compiled knowledge	Rewrite from current evidence	Readers need one usable current explanation.
Indexes, graphs, embeddings, context packets	Rebuild	Derived retrieval state must never become source truth.

Export is an authority boundary. Filter visibility and purpose before ranking. Export only explicit portable fields. Rebuild public text from an approved portable body or description; do not copy private deliberation or unknown fields into a public bundle merely because they parse as valid YAML.

Start retrieval with the cheapest measurable baseline. Add graph traversal for relationship questions. Add embeddings or reranking only after real queries show that the simpler path misses valuable evidence at an acceptable cost.

Dreamineering pages should be easy to export toward OKF because they already use markdown, frontmatter, semantic paths, and links. They should not weaken their local contract to match OKF's minimum. A touched page still needs the stricter page-type/template match described in Page Types.

Use This When

• checking whether a playbook page is machine-readable enough for external agents
• deciding whether an agent-facing contract belongs in /playbook/agents or should stay out of the public knowledge base
• deciding whether portable context is enough for an agent to act without asking Wik
• designing an export, manifest, or bundle format
• explaining why type, title, description, tags, links, and logs matter
• comparing local wiki rules to open knowledge-sharing standards

Checks

An OKF-aligned Dreamineering page passes when these signals are visible:

• type exists and matches Page Types
• page_job exists when the route is a repeated pillar, generated projection, or agent-facing operating page
• pillar exists when the route is a business or industry 5P page
• title and description explain the page job
• route and filename are stable semantic handles
• links have scent, not bare labels
• Context links use controlled relationship labels when they carry graph meaning
• DDL terms with homes resolve to real /playbook routes
• important pages have at least one proof edge or an explicit proof-state reason
• centrality is generated, not hand-authored
• current truth lives in public docs, while schema evolution is logged privately

Automation

Run the OKF audit before broad playbook metadata work:

pnpm playbook:okf

Apply the safe mechanical fields with:

pnpm playbook:okf:write

The script adds missing type, description, template, template_url, loop_phase, and level fields. It preserves nested YAML blocks such as instrument: and provenance maps. It treats nested index.md and index.mdx files as subject-navigation pages, which map to the local hub page type.

After the map is clean, run the value gauge:

pnpm playbook:okf:value

This report turns metadata into a cleanup queue. It shows weak descriptions, missing tags, template drift, orphan pages, weak link scent, and the highest-value hubs. Use it after generate-playbook-manifest.mjs so the report reads the current map.

Generate the meaning graph with:

pnpm playbook:okf:graph

Check typed targets and DDL homes without writing the generated JSON with:

pnpm playbook:okf:graph:check

The graph output lives at src/data/playbook-navigation/playbook-meaning-graph.json. It contains page nodes, DDL concept nodes, typed edges, normal markdown edges, validation issues, and derived centrality scores.

Failure Modes

• Minimum becomes ceiling — OKF requires type, but the local page still needs the right page type and template.
• Portable but weak — markdown exports cleanly, but links lack scent and agents cannot choose the next page.
• Path drift — the file path stops naming the concept clearly.
• Hand-authored mass — centrality is written into source data instead of derived from structure.
• Label drift — Context bullets invent relationship labels that the graph cannot compare.
• Log leak — private evolution history appears in public teaching prose.

Source Trail

• Github Repo
• Google Cloud: Introducing the Open Knowledge Format — source article for OKF v0.1.
• Page Types — local page-job authority.
• Wiki Schema — local Map-First edit and frontmatter contract.
• Information Architecture Standard — local placement, links, and answer-engine rules.

Context

• depends-on Purpose — the Tight Five root for why a page exists.
• applies-to Dev Flow — OKF pages become valuable when they help agents trace demand, spec, build, commissioning, and feedback.
• pairs-with Platform — portable knowledge formats become useful infrastructure when the platform can consume them.
• proved-by Performance — retrieval and answer quality should be measured.

Questions

What would fail if this wiki were exported as an OKF bundle tomorrow?

Next question: Which first-order route most needs typed Context edges next?

• Which page lacks a meaningful type?
• Which route depends on private context?
• Which links are present but carry no scent?
• Which generated projections need a portable manifest?