Third Brain V8.1 Skills

title: "Third Brain V8.1 Current-Model × Obsidian Blueprint" type: architecture-blueprint status: proposed version: "8.1.0-proposal" created: "2026-08-16" updated: "2026-08-16" decision_owner: vault-owner implementation_status: not-started

Third Brain V8.1 Current-Model × Obsidian Blueprint

Decision: keep the repository as the executable control plane, keep Obsidian Markdown as the canonical knowledge and evidence plane, and connect them through a transactional worker runtime. Use a serial command spine with bounded fan-out only for disjoint artifacts. No live-vault mutation is authorized by this blueprint.

1. Objective and boundaries

Objective

Evolve the current V8 scaffold into a resumable, evidence-bound pipeline that can safely ingest new material, retrofit previously imported concept pages to the Gold Standard, weave the Obsidian graph, and produce verifiable outputs at the scale of the current vault.

The target lifecycle is:

discover -> stage -> compile -> graph-plan -> independently verify -> commit -> archive -> optionally deliver

Non-goals

• Do not bulk-rewrite all existing notes.

• Do not mutate immutable source evidence to repair metadata debt.

• Do not let parallel workers write Home.md, 中央索引.md, shared MOCs, dashboards, or logs directly.

• Do not fabricate URL, author, date, source anchors, evidence, metrics, or counterarguments.

• Do not treat a successful process exit, file count, or placeholder artifact as semantic success.

• Do not bind the design to one fixed model name. Route work by capability and verify its artifacts.

• Do not archive a clipping before the committed artifacts pass their required gates.

2. Evidence-based starting point

The blueprint is based on a read-only inspection of the repository and the live vault on 2026-08-16.

3. System boundary and sources of truth

flowchart LR
    subgraph Repo["Repository — executable control plane"]
        Contracts["Schemas + templates + workflow contracts"]
        Runtime["Scheduler + state machine + compatibility adapters"]
        Tests["Contract tests + migration tests"]
    end

    subgraph Run["Transactional run boundary"]
        Command["Commander + command board"]
        Stage["Per-run staging + typed IPC receipts"]
        Integrator["Single integration owner"]
        Verifier["Independent governance verifier"]
    end

    subgraph Vault["Obsidian — canonical knowledge/evidence plane"]
        Inbox["Clippings / inbox"]
        Sources["Immutable sources"]
        Wiki["Concepts + entities + outputs"]
        Maps["MOCs + Home + Central Index + Canvas"]
        Ledger["Run receipts + debt queues + dashboards"]
    end

    Contracts --> Command
    Runtime --> Command
    Inbox --> Command
    Command --> Stage
    Stage --> Verifier
    Verifier -->|promotion receipt| Integrator
    Integrator --> Sources
    Integrator --> Wiki
    Integrator --> Maps
    Integrator --> Ledger
    Integrator -->|after commit| Inbox
    Tests --> Verifier

Contract publication rule

Every generated artifact records at least:

contract_version: "8.1.0"
template_id: "concept-gold-standard"
template_version: "8.1.0"
run_id: "run-..."
source_id: "src-..."
source_hash: "sha256:..."

The repository and deployed vault template must have the same declared version and content hash before a write-capable run starts.

4. Command program and team admission

This design applies the three required command lenses:

Team admission decision

• One clipping: no five-agent fan-out. One commander runs the serial spine, invokes deterministic tools, uses one semantic author where needed, and requests an independent verification context before commit.

• Two or more disjoint clippings/concepts: fan out only per-source and per-concept staging. Default semantic concurrency is 2 and remains configurable.

• Shared maps, indexes, dashboards, logs, archive state, and final promotion: always single-writer and serial.

• Consequential or low-evidence promotion: add a human approval gate; agent count does not substitute for evidence.

Command program

mission_id: obsidian-v8.1-<run_id>
objective: create evidence-grounded canonical knowledge without provenance or graph regression
non_goals:
  - rewrite_unselected_notes
  - fabricate_missing_evidence
  - parallel_write_shared_artifacts
commander: run-coordinator
integration_owner: vault-commit-owner
independent_verifier: governance-checker
shared_intent_hash: sha256(normalized mission + contract versions + permissions)
checkpoint_path: system/runs/YYYY-MM/<run_id>/state.json
command_board_path: system/runs/YYYY-MM/<run_id>/command-board.md
artifact_manifest_path: system/runs/YYYY-MM/<run_id>/manifest.json
max_attempts_per_failure_signature: 2
promotion_rule: all required receipts green + preimage hashes unchanged
stop_states:
  - NEEDS_INPUT
  - INSUFFICIENT_EVIDENCE
  - BLOCKED_DEPENDENCY
  - BLOCKED_PERMISSION
  - VERIFY_FAILED
  - NO_PROGRESS
  - BUDGET_STOP

5. Current-model execution strategy

The current model should be used where semantic judgment creates value; exactness belongs to deterministic tools.

The model receives a compact context_manifest, not the whole vault or a prior worker chat transcript. The manifest contains only the contract version, source identity/hash, selected evidence blocks, candidate target, relevant neighbors/MOCs, allowed paths, known baseline debt, budget, and stop rules.

6. Five worker contracts plus control roles

Control roles

• Commander: owns intent, task graph, leases, context manifests, budget, and recovery decisions.

• Integration Owner: is the only process allowed to promote staged files and mutate shared artifacts.

• Independent Verifier: evaluates staged artifacts and post-commit state; it cannot silently repair the author’s work.

Worker assembly

W5 is not a mandatory side effect of every clipping. A generic deliverable created only to make a pipeline look complete is a quality failure.

7. Typed IPC and durable state

Every worker returns the same envelope:

{
  "task_id": "task-...",
  "run_id": "run-...",
  "state": "DONE",
  "context_manifest": {
    "contract_version": "8.1.0",
    "vault_fingerprint": "sha256:...",
    "allowed_write_paths": ["system/runs/.../staging/..."],
    "budget": {"attempt": 1, "max_attempts": 2}
  },
  "artifact": [{"path": "...", "sha256": "...", "expected_preimage_sha256": null}],
  "artifact_hash": "sha256:manifest-hash",
  "evidence": [{"check": "source-anchor-resolution", "status": "PASS", "receipt": "..."}],
  "decision": {"promotion": "ALLOW"},
  "unknowns": [],
  "dependency": ["task-upstream"],
  "termination_reason": null,
  "next_action": "submit_to_governance"
}

State transition

DISCOVERED -> CLAIMED -> STAGED -> AUTHORED -> GRAPH_PLANNED -> VERIFIED -> COMMITTED -> ARCHIVED

• A failure transitions to one explicit stop state and persists evidence plus next_action.

• A retry resumes the failed node; it does not replay completed writes or append duplicate log entries.

• A repeated failure signature after a changed strategy stops at attempt 2.

• archive is legal only after COMMITTED and successful post-commit verification.

• A transient failure leaves the clipping in place. A terminal failure may invoke the existing fail queue action only after its failure receipt is persisted.

8. Transaction and write protocol

1. Preflight: resolve and fingerprint the vault; load contract/template hashes; record permissions and the global debt baseline.

2. Discover: scan queue without mutation; create source identities and an idempotency key from operation, canonical source identity, target, and run/batch.

3. Stage: workers write candidates only under system/runs/<run_id>/staging/.

4. Plan: produce concept/entity and graph deltas with expected target preimage hashes.

5. Verify: W4 checks schema, links, block refs, source immutability, placeholders, understanding, taxonomy, and no-regression rules.

6. Commit serially: Integration Owner rechecks identity and preimages, promotes canonical files, applies graph deltas in dependency order, and appends one idempotent receipt.

7. Verify post-commit: read touched files from disk and repeat the cheapest direct checks against final paths.

8. Archive: invoke the clipping archive adapter only after the commit receipt is green.

9. Close: persist the final manifest, update one keyed dashboard block, remove disposable staging, release leases, and record a short after-action review.

Rollback may remove or restore derived concept/map writes from the transaction manifest, but it must not erase original source evidence or append-only receipts.

9. Canonical concept template and retrofit lane

V8.1 template decision

Neither current template should be copied wholesale over the other. The V8.1 canonical template should merge:

• the live vault template’s flexible Mermaid topology selection, richer mechanism decomposition, URL/author/date fields, and five-dimension comparison matrix;

• the repo template’s explicit evidence level, knowledge stage, evidence boundary, falsifier, exact locators, actionable implications, governance constraint, and claim-level source anchors.

One schema should validate the data model; Markdown templates should be renderers of that schema. The live template named by the user is the structural/visual baseline for retrofits, with the stronger provenance gates restored before migration begins.

Previously imported concept retrofit

Run retrofits as a separate migration lane so they cannot block live clipping ingestion.

1. Build an immutable candidate manifest using import markers, source backlinks, template version, unresolved placeholders, or missing Gold-Standard sections.

2. Partition candidates by domain/MOC and source availability.

3. Classify each page:

   • STRUCTURE_ONLY: content is supported; normalize fields/sections without changing claims.

   • EVIDENCE_RESTORABLE: source exists; the reasoning author may rebuild semantic sections from resolvable anchors.

   • INSUFFICIENT_EVIDENCE: preserve the page, mark the debt, and do not invent missing content.

4. Generate a page-level before/after diff, source-anchor ledger, graph delta, and rollback entry.

5. Verify every changed claim and locator, then commit one bounded domain batch at a time.

6. Re-run touched-set lint and compare global health counts after each batch.

The first retrofit canary should be a small, representative set from one domain, including one clean page, one broken-source page, and one duplicate/title-collision case.

10. Governance and quality gates

Required touched-set gates

• Vault identity, contract version, and template hash match the run manifest.

• Source identity is unique at commit time; reruns converge to one canonical source and one logical receipt.

• Immutable source content equals its recorded SHA-256 after commit.

• Every required block locator exists and every derived claim resolves to an allowed source locator.

• Required YAML fields pass the note-type schema.

• No {{...}}, placeholder prose, generic metrics, or Pending Manual Review is accepted as success.

• New wikilinks resolve, or the artifact records an explicit reviewed isolation/debt decision.

• Concept pages pass the understanding gate: thesis, mechanism, boundary, falsifier/counterpoint, and reusable implication.

• Shared artifacts were changed only by the Integration Owner and their preimage hashes matched.

• Post-commit file hashes and archive state match the final manifest.

Global migration gate

Legacy debt is tracked separately from new defects:

• touched files: zero new P0/P1 findings;

• whole vault: no increase in broken source refs, unresolved links, missing required fields, or duplicate machine-owned dashboard blocks;

• debt reduction claims: only from fresh full or explicitly scoped scans with paths, exclusions, and counts.

Dashboard rule

Replace repeated appended snapshots with one marker-bounded block per dashboard producer, keyed by producer and snapshot type. History lives in run receipts, not duplicated dashboard sections.

11. Target project layout

contracts/
  vault-contract.yaml
  ipc/worker-receipt.schema.json
  notes/source.schema.json
  notes/concept.schema.json
  notes/entity.schema.json
  notes/output.schema.json
workflows/
  obsidian-worker-flow-v8.1.yaml
tools/
  worker_flow/
    cli.py
    engine.py
    state.py
    transactions.py
    stages/
    validators/
  worker_flow_engine.py              # compatibility facade during migration
tests/
  contracts/
  integration/
  migration/
system/templates/
  template-source-v8.1.md
  template-concept-gold-standard-v8.1.md
  template-output-deliverable-v8.1.md

Vault runtime state:

system/runs/YYYY-MM/<run_id>/
  command-board.md
  state.json
  manifest.json
  receipts/
  staging/
  rollback.json

Legacy entry-point disposition

12. Migration sequence

13. Acceptance test matrix

The implementation is not production-ready until these cases pass:

1. Fresh clipping with complete metadata creates one immutable source and one supported concept.

2. The same clipping rerun is a verified no-op and does not append a duplicate receipt.

3. Two workers racing on the same canonical URL converge to one source.

4. Missing author/date remains explicitly unknown; no field is fabricated.

5. A broken source anchor blocks promotion and leaves the clipping unarchived.

6. A concept containing an unresolved template token fails Governance.

7. A changed MOC preimage blocks the graph commit and preserves both candidate and recovery state.

8. A mid-run restart resumes from the last verified node without replaying completed writes.

9. A Governance failure can roll back derived writes without deleting source evidence or receipts.

10. Existing whole-vault debt does not block a clean touched set, but any regression does.

11. Retrofit of an evidence-poor concept returns INSUFFICIENT_EVIDENCE rather than synthetic Gold-Standard prose.

12. Dashboard refresh produces one current machine-owned snapshot and preserves historical receipts elsewhere.

13. W5 does not run without an explicit output trigger.

14. --audit reports actual YAML/link/block/source findings, scope, exit status, and reproducible paths.

14. Recommended approval package

Approve these defaults before implementation:

1. Architecture: repository control plane + Obsidian canonical data plane + transactional runtime bridge.

2. Authority: one merged V8.1 schema/template published with matching hashes; the live Gold-Standard template is the retrofit baseline, not an unversioned overwrite source.

3. Topology: serial spine, semantic fan-out capped at 2 by default, one Integration Owner, independent Governance.

4. Rollout: dry-run -> shadow -> one-domain retrofit canary -> bounded domain batches.

5. Safety: archive only after post-commit verification; no fabricated provenance; touched-set zero-regression gate.

After approval, Phase 1 should begin with contract/template reconciliation and acceptance-test scaffolding. Live-vault content migration should not begin until Phases 1–5 are green in an isolated test vault.

15. Temporal and live-vault rollout amendment

The vault owner subsequently expanded the rollout to include maps/, sources/, system/, and wiki/. This does not weaken the transaction boundary:

• time-sensitive claims carry freshness_tier, valid_as_of, last_verified, next_review, and freshness_status;

• the same URL with changed content creates a new immutable snapshot linked to prior snapshots;

• existing source bodies are never mechanically upgraded in place;

• live rollout begins with a read-only inventory, then a system-contract deployment, one new project source/concept, and one evidence-restorable concept retrofit;

• map changes remain marker-bounded and single-writer;

• domain batches advance only when touched-set P0/P1 findings stay at zero and whole-vault debt does not regress.

The verified baseline and selected canary are recorded in docs/live-vault-v8.1-baseline-2026-08-16.md.