Running the project.
The first goal is a reproducible, containerized deployment on one supported Linux VM. This page will become the versioned installation guide when the first runnable release is available.
There are no product installation commands to run today. The deployment steps below describe the intended experience and the checks required before a release.
Choose a planned deployment path
| Path | What it will require | Status |
|---|---|---|
| Azure reference VM | A test subscription, a scoped test storage account in Canada Central, and approved access to Azure management and identity services. | First implementation target |
| Existing Linux host | A supported host with administrative setup access, adequate local resources, and permitted connectivity to the chosen target. | Planned validation path |
| Disconnected environment | Local targets, an approved offline artifact bundle, internal dependencies, and a controlled transfer process. | Later milestone |
Exact operating-system versions, CPU, RAM, disk, model selection, and optional GPU requirements remain to be benchmarked and documented. No supported hardware minimum is being claimed yet.
The intended installation experience
- Prepare or validate the host
The bootstrap recipe should check the operating system, runtime, network policy, service identities, and storage. An Azure recipe may provision a reference VM; an existing-host recipe should validate the machine it is given.
- Verify the release bundle
Verify publisher identity, signatures, digests, and the manifest before loading containers, local model artifacts, policies, or supporting packages.
- Declare the target and policy
Configure the selected resource, desired state, allowed operations, approval requirements, evidence location, and recovery options. The initial configuration interface is planned around YAML and a CLI.
- Start the separately permissioned services
Load the collector, local model, policy, broker, verifier, and evidence components. Validate that the model cannot obtain the executor’s credentials or bypass the approval path.
- Run the reference scenario
Observe the synthetic test account, inspect the proposed fix, approve the exact change, execute it, and verify the resulting setting independently.
- Inspect and recover the evidence
Inspect the observation and decision chain, verify its signature, export the encrypted local recovery package, and test restoration.
Before calling it a runnable release
- A fresh supported host can install a named release using the documented steps.
- The selected Azure setting is repaired only after policy evaluation and human approval.
- Unapproved, out-of-scope, altered, expired, or replayed changes are rejected.
- The model cannot access the cloud credentials or privileged execution interfaces.
- Independent verification detects a failed or incomplete repair.
- A modified evidence package fails verification, and the original package can be restored locally.
- The release lists its exact dependencies, required network destinations, known limitations, and test results.
What a future quickstart will contain
A tested version and download location; supported host specifications; checksums and signature-verification instructions; actual installation and configuration commands; one synthetic walkthrough with expected results; upgrade, rollback, uninstall, and recovery instructions.
Until those exist, start with the architecture and follow the roadmap. The website is a project information site; it is not the runtime and does not establish an air gap for a deployment.
Design documentation · Updated 15 September 2026 · Nomiarch · Architecture in development.