Shared System Model
Why developers, CI, IDEs, and AI agents need governed views of the same software-system truth.
A shared system model is a governed representation of the software system that multiple consumers can inspect without reconstructing reality independently.
Shared does not mean that every consumer sees the same payload. It means their views are projections of the same model and evidence.
The drift problem
Without a shared model, each surface develops a private interpretation:
These interpretations age differently. A green CI result may describe an older revision. An IDE may index only the open repository. An agent may receive a curated prompt with no freshness information. Each answer can be locally reasonable while the system-level answer is inconsistent.
Model and views
The shared model contains durable identities and relationships:
- projects, repositories, services, and runtimes;
- dependencies, contracts, ownership, and policies;
- commands, generated artifacts, and verification gates;
- observations, evidence references, freshness, and uncertainty.
Consumers receive scoped views:
| Consumer | Useful view |
|---|---|
| Developer | affected projects, safe commands, current blockers |
| CI | deterministic gates, required evidence, policy state |
| IDE | active project boundaries and navigation relationships |
| Agent | allowed scope, facts, unknowns, commands, verification expectations |
The view can differ without producing a different source of truth.
Governance requirements
A model is not shared merely because it is stored in JSON. It needs:
- stable identities and versioned contracts;
- explicit producer and consumer boundaries;
- evidence provenance and freshness;
- conflict and invalidation rules;
- deterministic validation;
- compatibility rules for model evolution.
The Workspace Model is Workspai's current implementation surface for part of this idea. The mental model is broader than that implementation and should remain useful to other tools and standards.