Product / Governance
Structure that stays true after it is applied
Governance is what happens between applies: verifying the workspace against the declaration, reporting where the two have diverged, and repairing only what Orvienm owns.
Structural policy
A specification is a policy, not a one-time instruction. It states the structure a workspace is expected to have, and it keeps stating it after the first apply has finished.
That makes structure checkable. A workspace either matches its declaration or it does not, and the difference can be produced on demand rather than discovered when something breaks.
Verify
Verify compares workspace state against expected structure. It reads the specification, walks the paths it declares, and reports each one as present, missing, or present but undeclared. It changes nothing.
What verification reports
- Present
- Declared, and found in the workspace.
- Missing
- Declared, but absent from the workspace.
- Undeclared
- Found in the workspace, but not part of the specification.
A workspace has converged when verification reports no difference. Convergence is a state you can check for, not a promise made at apply time.
Drift
Drift is what verification finds when reality has moved away from the declaration. A directory was renamed by hand, an environment was set up from a stale template, a migration half-finished.
Detection is not correction.
Orvienm reports drift and stops there. It does not decide on your behalf that a difference should be resolved, or in which direction. Deciding what a divergence means is the part that needs a human or an explicit policy, and hiding it inside an automatic fix would remove exactly the signal governance exists to produce.
Conservative repair
When you do ask Orvienm to close a gap, it repairs conservatively.
- Creates what is missing
- Paths the specification declares but the workspace lacks are created.
- Preserves what it does not own
- Paths present in the workspace but absent from the specification are left exactly as they are.
- Removes nothing implicitly
- Being undeclared is not a reason for deletion. There is no automatic cleanup pass.
The asymmetry is deliberate. Creating a missing directory is recoverable; removing a directory somebody else depended on is not.
Provenance and traceability
Structure carries a deterministic identity, so a materialised workspace can be tied back to the specification and state that produced it. Two runs that produce the same structure produce the same identity; a change in structure changes it.
The same principle extends to the Content Layer and grounded Ask, Alpha capabilities of Orvienm Studio rather than of the command line engine: content can be scanned into deterministic units that carry provenance, and Ask answers from those cited units or declines when it has nothing to cite — a fail-closed answer rather than a plausible one.
What is recorded
The command line engine records one thing: the fingerprint of the specification a workspace was built from, written to a lock file on the first apply that creates a structure. That single record is what makes drift detectable — a changed specification no longer matches what the workspace was built from.
It is deliberately not a run log. The engine keeps no snapshot store and no execution history; run-by-run history is a capability of Orvienm Studio, not of the CLI. What the lock file contains and how drift is evaluated are documented in the Specification Reference.