From Repository to Workspace Model
How source containers become an evidence-backed representation of projects, relationships, policies, and operational state.
A repository is an input boundary. A workspace model is a derived system view. Moving between them requires explicit stages.
1. Discover
Observe repositories, manifests, runtimes, configuration, CI definitions, contracts, ownership signals, and existing workspace metadata. Discovery should record what was actually observed rather than immediately promoting every signal to truth.
2. Identify
Assign stable identities to projects, services, contracts, commands, policies, and artifacts. Paths are useful locators, but they are fragile identities when repositories move or a workspace spans multiple roots.
3. Relate
Connect entities through typed relationships:
- contains and belongs-to;
- depends-on and implements;
- produces and consumes;
- owns and governs;
- changes and affects;
- verifies and blocks.
4. Attach evidence
Each important fact should retain its source, observation time or revision, confidence, and freshness. Conflicting observations should remain visible until governance resolves them.
5. Project views
Generate task-specific outputs for humans, CI, IDEs, and agents. A view is a projection of the model, not an independent rediscovery pass.
The Workspace Graph expresses relationships; the Workspace Model defines the current structured view. Together they move tooling from repository indexing toward software-system understanding.