Skip to content

Structure as code

Hyper Reality Semantic as Code

Today, Orvienm operates on structure defined declaratively and executes change deterministically. Declare the structure a system should have, see the exact changes before they happen, apply them, then verify reality against the declaration.

Get StartedDocumentation
  1. Define
  2. Validate
  3. Plan
  4. Apply
  5. Verify

Representation

Same structure. Two representations. One system.

A directory hierarchy and a declarative specification describe the same thing. Orvienm treats the specification as the contract and the filesystem as the state that contract governs — so structure stops being something you reconstruct by reading a tree.

Structure on disk

  • platform/
  • core/
  • data/
  • docs/

structure.yaml

version: 1

structure:
  name: platform
  directories:
    - core
    - data
    - docs
How the specification works

Lifecycle

Every change passes through five stages.

Nothing reaches the filesystem before it has been declared, checked and shown. The same specification against the same state produces the same plan.

  1. 01

    Define

    Declare the structure the system should have.

  2. 02

    Validate

    Check the specification before anything is executed.

  3. 03

    Plan

    Show the structural changes an apply would make.

  4. 04

    Apply

    Execute the plan, creating what is missing.

  5. 05

    Verify

    Compare the workspace against the expected structure.

Inside the engine

Governance

Change is governed, not assumed.

Applying a structure once is easy. Keeping a system honest about the structure it is supposed to have is the harder problem, and it is where Orvienm does most of its work.

Verify
Compares the workspace against the structure the specification declares, and reports where the two disagree.
Drift
What verification finds when reality has moved away from the declaration. Detection is reported; it is not silently corrected.
Conservative repair
Creates what is missing and preserves what it does not own. Paths absent from the specification are left in place, never removed automatically.
Provenance
Deterministic identity for structure and content, so a result can be traced back to the specification and state that produced it.
How governance works

Language

A specification, not a script.

You describe the structure a system should have, not the steps to build it. Nesting expresses containment, and the specification is read as a graph — nodes and the relationships between them — which is what makes validation, planning and verification possible over it.

The same definition can be validated before anything runs, compared against a workspace, and reasoned about as a whole rather than file by file.

The declarative model

Where it applies

Where structure stops being implicit.

Orvienm is useful wherever the same shape has to hold across repositories, environments and teams, and where discovering that it no longer holds matters.

Project structure

Give every repository, service and workspace the same shape, declared once and applied wherever it is needed.

Infrastructure and DevOps

Keep environment, pipeline and service layouts consistent instead of reconstructing them by hand per environment.

Automation inputs

Give automated processes a structure they can rely on, defined explicitly rather than inferred from whatever exists.

All solutions

Start with a specification.

Orvienm is in Alpha. The CLI is installed from source for people who have access to it — there is no package index entry and no binary release yet.

Getting StartedDocumentation