Vialsosmograph.domain-pack/2osmograph.vial-host/1

A Vial is a programmable anomaly app.

It has three parts that ship together: a profile program that declares what counts as a relevant change on one array and one process, a domain UI that turns that change into a decision surface, and evidence that shows the program works on held-out data. The host runs the detector and owns every safety refusal. The Vial programs the interpretation, the presentation, and the limits.

The definition in one sentence

A Vial is a versioned, hash-pinned program for one repeated decision: its manifest declares the baseline, transforms, detection thresholds, persistence, hysteresis, escalation, admissibility, and evidence; its sandboxed UI renders the host snapshot; its fixtures and held-out report show the declared behaviour is real.

Why this is programmable

The program is the part that changes what the instrument does. When a Vial is open, the host compiles its profile into a detector owned by that Vial. Two Vials can watch the same array at the same time with different warm-up windows, persistence, hysteresis, and escalation. Neither can change the other, and neither can raise the base app's alert level. A folder of text and a screen can describe a workflow; the profile is what makes the workflow run.

Layer	Owned by	What it decides
Profile program	The Vial manifest	Baseline protocol and warm-up, response transform, per-channel limits, minimum channel corroboration, level budget, persistence, hysteresis, escalation, reset, and the false-alarm target.
Domain UI	The Vial's sandboxed <Code>ui.html</Code>	What the user sees and can do: context fields, checks, logs, diagrams, stop rules, and a Home contribution. It receives typed host state and returns bounded actions.
Runtime	Osmograph	Sampling, baseline health, Kalman detection, sensor faults, the sandbox, hashing, schema validation, and every safety refusal.
Evidence	The author, checked at review	Held-out report, dataset provenance, measured FAR/latency/MDE, and fixture cases that `noses test` replays against the profile state machine.

The lifecycle, end to end

author → list → install → operate

author writes vial.json + ui.html + fixtures/
        │
        ├─ noses lint     schema, profile, evidence, sandbox, placeholders
        ├─ noses test     runs fixtures against the declared profile
        └─ noses publish  manifest sha256 + every UI asset sha256 + registry entry
        │
        ▼
POST /api/vials/submit  →  GitHub issue with pinned hashes
        │
        ▼
/admin review  →  re-fetch, re-validate, refuse changed bytes  →  commit registry.json
        │
        ▼
Aromatory open  →  fetch manifest + assets  →  verify hashes  →  run the same host gate
        │
        ▼
install  →  per-Vial detector  →  domain UI  →  report a problem with id/version/hash
        │
        ▼
new version  →  registry pins it  →  “Update to vX” in the Aromatory  →  hash-verified replace

Tutorials

Quickstart

Scaffold, fill the profile, write a fixture, run the gate, publish, and install.

The profile program

Baseline, transforms, persistence, hysteresis, escalation, admissibility, and the false-alarm budget.

The domain UI

The sandboxed iframe, the typed host snapshot, the action set, and the presentation laws.

Evidence and fixtures

Held-out reports, fixture format, what `noses test` proves, and what review actually checks.

Install and operate

Hash-verified install, updates, per-Vial bug reports, offline behavior, and rollback.

Reference

Every schema field, bridge method, snapshot field, status, and command in one place.

What a status means

Status	Where it comes from	What it claims
Draft	Local edit	Not installed. The author is still writing the profile, UI, or evidence.
Ungated	Local gate failed (`open` in the registry)	Installable for development. A critical check failed or the v2 profile has no fixture; the host says so and does not present it as validated.
Gated	Local gate passed with at least one fixture	The manifest, profile, UI sandbox, citations, evidence block, and at least one declarative fixture satisfy the local contract; external review is a separate step.
Reviewed / listed	Registry review	A person reviewed the claim and evidence, and the registry pins the manifest, UI, and fixture hashes. The host still re-runs the gate and verifies the manifest and UI bytes on install.
Signed	External signature	An external signature, recorded separately. Signing is outside the local gate.

Caveat

A listing records a human review of a claim. The host never lets a Vial override a sensor fault, a baseline refusal, or the base alert level. Every install re-verifies the bytes; nothing is trusted because it appeared in a catalog.

The invariants that make the system antifragile

One gate, two implementations, one fixture corpus. The desktop and noses both gate manifests. A disagreement becomes a conformance fixture.
Every failure becomes a fixture. A bug report that names a Vial id, version, and hash can be replayed. The fix adds a fixture; the fixture runs in noses test and in the release check.
No fake numbers. The registry and UI refuse to invent a measurement. A Vial without a held-out report or a fixture is Ungated, and a profile without a false-alarm target says so.
The program is pinned. The registry pins the manifest sha256 and every UI asset sha256. An upstream edit cannot silently replace a reviewed Vial; the install refuses and the update path reports the mismatch.
The host owns the brakes. A Vial can tighten its own profile; it cannot loosen the host's refusal, hide a sensor fault, or turn a warming baseline into an alarm.

Start here

If you have never built one, read the quickstart. If you already have a protocol, read the profile and evidence chapters before you write a UI. The profile is the product; the UI is how a person uses it.

Build your first Vial Browse the Aromatory