Infrastructure for Intent: Moving from Retrieval to Relationship

This system did not begin as a knowledge platform or business operating system (BOS). It started from a much narrower obsession: preserving intent integrity and intent fidelity over time.

By intent fidelity, I mean whether explicit instructions, decisions, or state are preserved accurately. By intent integrity, I mean whether the operational meaning behind those decisions remains coherent as work evolves across time, projects, summarisation, delegation, AI mediation, and organisational drift.

That distinction gradually led me toward building what eventually became a shared operational context system that I now use daily across development, writing, and project management work.

The Decay of Operational Context

I did not set out to build a generalised AI platform. Most of the architecture emerged incrementally under operational pressure while trying to solve a persistent problem: operational context decays faster than most systems acknowledge.

Projects drift and documentation becomes partially stale. Rationale disappears. Relationships between systems weaken over time. AI systems often amplify the problem because they operate against fragmented or outdated context while presenting answers with high confidence.

A large amount of engineering and operational work is actually spent reconstructing continuity:

• Why something exists and what assumptions were present at the time.
• What else may now be affected by a change.
• Whether documentation still reflects the actual implementation.
• Which operational decisions relate to current work and what changed elsewhere while attention was focused locally.

Most tools treat projects, repositories, documents, and conversations as relatively isolated contexts. In practice, operational work is not isolated. Decisions and changes propagate continuously across systems, documentation, code, planning, and people.

Building the Shared Substrate

The system I ended up building is local-first, markdown-first, and git-auditable. Human-readable markdown remains the primary operational source of truth, but semantic state is continuously projected into a structured knowledge layer.

The system remains local-first and markdown-anchored, but it is no longer static. By moving toward a standardised framework for code and abstraction, we’ve made the substrate extensible. It allows for the injection of agentic capabilities and custom automation without compromising the human-readable source of truth. We can now extend the system's reach while keeping the weight and authority exactly where it belongs: on the local machine.

All projects inherit shared operational context from a common PIR layer containing:

• Shared knowledge and operational conventions.
• Skills, governance rules, and lineage structures.
• Tagging relationships and policy enforcement.
• Agent capabilities.

The important operational shift was that context stopped being trapped inside individual repositories or transient AI chat sessions. I can now enter a project context and query relationships across unrelated workstreams: what documentation may now be stale, what assumptions were affected by a change, and what prior rationale connects to current work.

One surprisingly useful capability is simple change awareness. After modifying a file, I can ask the system what else likely requires updating: documentation, references, related code, operational notes, or linked decisions. This sounds trivial, but in practice, it reduces a surprising amount of missed context and fragmented follow-up work.

Governance and Cognitive Mobility

The system also gradually evolved toward stronger governance and policy enforcement. I have become increasingly intolerant of partially trustworthy systems. In practice, partially stale operational context quickly becomes globally unreliable because humans stop trusting the system as a whole. For that reason, the system relies heavily on deterministic enforcement underneath probabilistic AI tooling:

• Policy-backed guardrail scripts and git-based auditability.
• Bounded agent access and governance structures.
• Separation between human-only and agent-accessible knowledge.
• Lineage and traceability.

Agents are treated as replaceable cognition providers rather than authoritative operational sources of truth. The architecture is model-agnostic and local-first; all data remains local even as the 'intelligence' layer expands. Crucially, the system preserves the option for a completely closed loop. For projects requiring absolute privacy, the orchestration layer can be constrained to strictly local execution, ensuring that both intent and cognition remain entirely on-device. This sovereignty mandate ensures that total privacy is a configuration choice rather than a platform constraint.

To maintain performance on local hardware, I've used DSPy to optimise local agent signatures and skill usage, ensuring that even smaller local models can execute complex vault operations with high reliability. More importantly, the implementation of a Model Context Protocol (MCP) layer has allowed for a sophisticated orchestration model. Instead of relying on a single generalist model, the system now uses an orchestrating AI to route specific tasks to subagents chosen based on their capability ratings for the work at hand.

The PIR framework allows for this kind of cognitive mobility; I can shift the 'cognition' to whichever model or subagent has the required capability rating while the intent and authority stay anchored on the local machine. Older agent skills have gradually been refactored into more standardised A2A-compatible structures. The semantic layer has evolved from lightweight filesystem projections toward increasingly queryable operational state. Most of the architecture emerged iteratively rather than through top-down design.

The Human Boundary

At the same time, I am very aware that systems built for highly disciplined operators often fail outside their creators. I am unusually intolerant of drift. I aggressively correct inconsistency, stale context, and semantic degradation as soon as I notice it. Most users will not operate this way, and systems that depend on constant manual rigour rarely scale socially.

That realisation is largely what pushed me toward building a separate BOS layer. The underlying operational substrate is intentionally strict (governed, auditable, and lineage-aware), but the BOS layer exists to absorb that complexity and reduce operational burden for normal users. The goal is not to force users to think like infrastructure engineers, but to preserve operational continuity underneath workflows that remain usable and cognitively lightweight.

Conclusion: Continuity as Infrastructure

I do not think I have solved operational continuity, context drift, or intent degradation. I suspect these problems never fully disappear. But after nearly a year of sustained daily use, I think there is something useful in treating operational context as infrastructure rather than as disconnected repositories, notes, conversations, or transient AI sessions.

The most valuable outcome so far has not been automation. It has been continuity.