Implementation Audit

An architecture doc will tell you the Living Force is real. It will not tell you which repository it lives in, whether the runtime on the actual machine still matches the drawing, or how much of it is held together by local state and one session’s memory. So we sat down and counted.

Tommy supervised — which is to say he lay across the service manifests and watched, the way he watches anything he suspects cannot survive a reproduction step. The verdict came back reassuring and specifically humbling. The codebase, runtime, and operational tooling mostly back the architecture up, but not in one repository and not from one source of truth. Sanctum is a federation: checked-in workspace code, ~/.sanctum runtime state, and shared implementation in ~/Projects/openclaw-skills/.

So the useful question is not whether the Living Force is real. It is. The useful question is where the real implementation lives, what is cleanly source-controlled, and what is still held together by local state and memory.

What Was Verified

The implementation audit confirmed these components exist and are wired into the running system:

• service-graph.py and the surrounding graph-oriented test harness in the shared skills layer
• navigator-sidecar.js in the workspace, serving aggregate project status over HTTP
• The Rust watchdog in ~/.sanctum/sanctum-watchdog, including its local API, anomaly detection hook, and incident-learning hook
• The genome-mcp repo in ~/Projects/genome-mcp, including its CLI, ten-panel analysis surface, and exported health profile
• The Code Forge pipeline in ~/Projects/openclaw-skills/code-forge/tools, including proposal, validation, deploy, rollback, review, and list commands
• Checked-in Sanctum service manifests under sanctum/services/
• Runtime configuration in ~/.sanctum/instance.yaml
• LaunchAgent-based operational wiring under ~/Library/LaunchAgents

What Changed During Consolidation

The workspace-owned slice was tightened first:

• sanctum/catalog.yaml is now the canonical checked-in service catalog for the workspace manifests
• sanctum/render_services.py deterministically renders sanctum/services/*.yaml from that catalog and holocron-config.yaml
• sanctum/agent_capabilities.yaml is now the canonical checked-in permission model for Code Forge, and ~/.sanctum/scripts/sync_agent_capabilities.py syncs it into ~/.sanctum/config/agent-capabilities.yaml
• tools/sync_runtime_calibration.py now checks the remaining runtime-generated calibration surface: ~/.sanctum/.instance.json and the template-managed LaunchAgents derived from instance.yaml
• tests/test-sanctum-audit.sh validates config rendering, service graph compatibility, sidecar behavior, and documentation wiring
• tests/test-sanctum-immune-system.sh now proves the live watchdog can self-heal a degraded graph, record incidents, expose its API state, and preserve degraded truth when remediation fails
• tests/test-sanctum-code-forge.sh now proves the shared Code Forge scripts can propose, validate, deploy, roll back, review, list, and audit real proposals end to end
• tests/test-sanctum-evolution-loop.sh now proves the real incident-learning, performance-review, and weekly evolution-report scripts form a working loop that writes memory artifacts and audit entries
• tests/test-sanctum-genetic-health.sh now proves genome-mcp can run all ten panels locally through its checked-in virtualenv without depending on private live genome data
• tests/test-sanctum-tech-lookout.sh now proves the real tech-lookout scan, brief, and dispatch scripts work as a local pipeline even in a clean disposable home
• navigator-sidecar.js now exposes aggregate status, scrubs obvious secrets, and supports env-configured paths and port selection

Tip

The key improvement was not another diagram. It was making one path through the system mechanically reproducible. A configuration model you can re-render is worth more than a promise in a paragraph.

Current Split Of Truth

There are still three layers with different responsibilities:

Layer	Path	Current role
Workspace	~/Documents/Claude_Code	Checked-in manifests, renderer, sidecar, audit tests
Runtime	~/.sanctum	Live instance config, wrappers, scripts, generated state
Shared skills	~/Projects/openclaw-skills	The larger Living Force and service-graph implementation

That split is workable, but it means any claim about Sanctum needs to say which layer it is talking about. Without that, the docs sound cleaner than the system really is.

Main Findings

1. The architecture is materially real. The graph-based healing and watchdog doctrine are not fiction. Core scripts and test harnesses exist and now include a direct end-to-end proof against the live Rust watchdog binary.

2. The runtime calibration story is now much tighter than it was. The checked-in manifests already had canonical renderers. The remaining runtime-generated artifacts now have explicit calibration checks too, so the live machine is less dependent on “probably current” assumptions.

3. Documentation drift was caused more by boundary confusion than by missing code. Older prose mixed stable architecture, dated migrations, and current operational claims into a single narrative voice.

4. Absolute paths and machine-local assumptions remain the main portability risk. Sanctum works like private infrastructure, not like a portable product, until more of the runtime model is rendered from source-controlled inputs.

Related Pages

• Feature Status Matrix for the evidence-backed implemented/partial/documented split
• Operational State for the current verified shape of the system
• Runtime Drift Audit for the live ~/.sanctum and LaunchAgent remediation work
• Operational History for the dated milestones and migration notes

The architecture held up under inspection. The remaining work is consolidation, not invention — less glamorous than a new diagram, and much cheaper than another 4 AM surprise. Tommy has already moved off the manifests and back to the windowsill. He only supervises work he expects to hold.