The gates as release evidence, our checks on the product, recorded against a commit.
What you will achieve
Use this page to read a release-check transcript and identify the version tested. It explains how uncommitted changes limit what the results establish. You will not run the gates on a customer host. This page describes the evidence Novus produces before a release. Operators can identify the checks performed and the commit tested.
What it is for
Before a release, Novus runs a fixed set of checks against the product. Those checks are the release evidence. They say which commit the product was built from, which checks passed on it, and how long each took. The customer’s own confidence in a release rests on that record, together with the release manifestRelease manifestThe file recording the exact software versions and fingerprints used for a NovusLens release candidate. Installation checks compare files against it., which holds the sha256SHA-256A method that turns content into a fixed-length fingerprint. Comparing fingerprints helps check whether content changed. values the checks ran on.
The gates are not checks on a customer’s agentsAgentA program that takes actions for an organisation. NovusLens records what it is allowed to do and what its activity reports show.. They do not read a customer’s estate, and they do not judge a customer’s systems. They test the NovusLens product itself. What a customer’s own estate looks like is for the customer’s twinTwinNovusLens’s model of one organisation, built from records about its teams, services and how they rely on one another. It is only as current as those records. to show, through the evidence the customer’s own sources provide.
How it works
./lens ops --version dev gates runs the twelve gates in this order: smoke, test, steel, fresh, ask, federation, agents, domains, e2e, kit, boundary, durable. It runs them one after another, and it records a result and the seconds each gate took. ./lens ops is the development driver. It runs on Novus’s development machine, not on a customer host. Customer installations use the Compose commands.
The runner writes docs/gates/<date>-<sha12>.md, where <sha12> is the first twelve characters of the commit. The transcript records:
- the head commit, with its one-line subject;
- whether the working tree was clean, or
DIRTY, with the list of uncommitted files; - the time the run started and finished;
- a table with one row per gate: its name,
PASSorFAIL, and the seconds it took.
The per-gate logs are written to /tmp/novuslens-gate-<gate>.log on the machine that ran them. The transcript is committed in the next commit, so it always refers to the commit it was run on, not to itself.
What the named gates exercise
Four of the twelve gates are explained below. The others are described in the header of their function in ops.
| Gate | What it exercises |
|---|---|
test | Starts the database, applies migrationsMigrationAn ordered change to a database's tables or rules. Applied migration files are recorded so the same file is not run again. and creates development viewers. It starts a fresh meshMeshA set of connected Mycelium services that exchange updates and keep the NovusLens log. and the opa and cedar policy engines. It runs the GuideGuideThe help pages inside NovusLens. They explain the pages, input formats and tasks in the version you use. They are product instructions, not evidence about the organisation. check, full test suite and skip check. The skip check refuses a skipped test unless its path and reason match an allowed pair. It also runs the supply-chain auditSupply-chain auditA check of the software packages the product depends on against reported security problems. An incomplete report cannot pass.: pnpm audit --prod for the web application and pip-audit on the locked Python set. Any advisoryAdvisoryA published report of a security problem in a software package. that config/audit-triage.json does not record as fixed, mitigated or not applicable fails the gate. |
steel | two browser-verified acts of the product’s main story: streaming telemetryTelemetryMeasurements and activity records sent by a running system, such as ticket timings, network traffic or workflow results. and a correctionCorrectionA change to a recorded value or record. The earlier version stays in the history, and any conclusion that depended on it is checked again., then the recalculation of the dependency-chain index. The gate fails if the expected correction or the expected findingsFindingA difference in the records that needs a decision. It includes its sources and can describe a slow handoff, disputed fact or missing owner. are missing. |
boundary | the public boundary of the customer profileDeployment profileA setting that selects customer or development behaviour. Customer mode refuses development credentials and uses the signed-in session as the identity.. In that profile identity is the login session and nothing else. The gate exercises this through the web application’s proxyProxyA service that receives a request and forwards it to another service. The NovusLens web proxy adds the signed-in identity and service token. and at the reasoning service, and never through Python calls that already know who is calling. |
durable | the canonical commit log survives a restart of the persistent nodes and a backup and restore round trip. The materialiserMaterialiserThe component that reads recorded changes in order and updates the database. It records its place so it can continue after a restart. checks that its saved position still refers to the same log. It fails when that log has gone. |
The supply-chain audit is a completion check as well as a findings check. A report that is empty, malformed or missing fails the gate with the reason, rather than passing silently.
Reading a transcript
The example in the repository, docs/gates/2026-10-02-fdffa5ef8d1b.md, shows the format. Read it in this order:
- Check the head. A transcript is evidence for the commit it names and for nothing else.
- Check the tree line.
tree: cleanmeans the run was on the committed state.tree: DIRTYmeans uncommitted changes were present, so the transcript shows what happened on a working tree and not on a commit. A release relies on a clean run. - Check every row. A release relies on twelve
PASSrows. AnyFAILrow names the gate, and its log is on the machine that ran the gates.
Interfaces
The gates are run from ./lens ops --version dev gates, and each gate can be run on its own with ./lens ops --version dev <gate>. ./lens doctor checks the running installation and prints repairs. Deployment runs those checks before reporting sign-in details. The gates collect evidence about a release; doctor checks the installed configuration and build.
Invariants and failure behaviour
- A transcript records the tree state. A dirty tree is recorded as dirty, not hidden.
- A gate that cannot account for a skip fails. The test gate does not count a skipped test as a pass.
- The release manifest records the sha256 values the gates ran on. The installation checks refuse a sidecarSidecarA separate supporting process that runs beside the application. Here it runs Mycelium and exposes the gateway that NovusLens calls. or SDKSDKSoftware development kit: a package of code that helps another program use a service. NovusLens uses mycelium-py to talk to Mycelium. that differs from them, so the manifest and the bundle must agree.
- The manifest describes its release as a candidate, not as a shipped release. The gates produce evidence for a candidate; a release is a separate decision.