optionOS optionOS

Connect documentation blocks with unique anchors, one authority and lineage

Where is AI going?
Tags
  • PREDICTIONAn unproven bet that can change future decisions.
  • ACTIVE-USECurrently in use.
  • EXPECTED-RETURNExpected value exists; return is not proven yet.
  • NOT-SCALEDNot yet scaled across independent cases.
  • NOT-EXITEDNot abandoned; no exit reason.
  • CONTEXT-FORESTMulti-document AI context forest.
  • LINEAGEParent/child/relation lineage is required.

When an AI reads many prompts, policies, skills, guides and notes, it no longer sees one document at a time; it receives a large context forest. A small but important block can disappear when its larger parent idea is not visible.

This page is a prediction, not a proven result: if every decision-bearing documentation block carries an objective [namespace:key], parent/root relation, relation, authority, projection boundary and judge, humans and agents can rebuild the big picture more reliably.

A correct node name is not subjective. Value words like good-lineage, clean-docs or obvious-tree are not names; they must compile into observable axes first. A good access key names the observed subject: context-forest, prediction-lineage, node-index, file-policy.

A correct node does not overlap. Source truth lives in one place; Guide, HTML and generated graphs are projections. If similar information repeats, it must carry a different lineage and a different reader decision; otherwise it is merged, split or demoted to projection.

Minimum shape: unique id → parent/root → relation → receiver decision → authority → projection boundary → judge.

Example: [base:1] reads like a parent node, and [base:1.1] is its child block. [file:source-file-policy] is the file authority, and [file:1] is its meaning block. The reader answers “where does this block belong?” from lineage instead of line numbers or memory.

base-prompt.md showing base namespace anchors
`[base:1]` reads as parent scope; `[base:1.1]` reads as child block.

First visual evidence for Context Forest: blocks inside a large prompt are addressable by unique namespace anchors.

  1. 1`[base:1]` — parent scope / main node
  2. 2`[base:1.1]` — child block / sub-node
file.policy.md showing file namespace anchors
`[file:source-file-policy]` reads as authority root; `[file:1]` reads as meaning section.

Second visual evidence: the same anchor/lineage approach works inside a policy file.

  1. 1`[file:source-file-policy]` — file authority / source root
  2. 2`[file:1]` — meaning section / child block

Falsifier: if anchors and lineage do not help agents recover the right parent/authority, do not reduce duplicate/orphan decisions, or only add scan noise, the prediction gets weaker.