07 Deployment View
This chapter specifies where Prism’s containers run and how they reach
the actors who depend on them. Prism is a library distribution system:
its three crates (uor-foundation, prism, prism-verify) are not
deployed as services, are not hosted on any server, and do not run in
any cloud. Instead, the crates are compiled by application authors and
verifiers into executables that run on those parties' own hardware.
This is a normative deployment property. Constraint TC-06 (no application-author infrastructure) requires that no service operated by the application author be required for the application to function or for the user to verify outputs. The deployment view’s job is to specify the infrastructure topology consistent with that constraint.
Three deployment environments exist in Prism’s deployment view, corresponding to the three external actors named in section 3:
| Environment | Owner | Resident artifacts |
|---|---|---|
| Application author’s compilation environment | The application author | Source files of the author’s crate; cached compilations of uor-foundation, prism; the Rust toolchain (cargo, rustc); the compiled output executable. |
| Application user’s execution environment | The application user | The author’s compiled executable (which includes prism's pipeline runtime as compiled code, plus uor-foundation's mint primitives and type definitions); runtime input data the user provides; runtime outputs the executable produces (sealed values, traces, certificates). |
| Application user’s verification environment | The application user (may coincide with the execution environment, or be distinct) | A verification executable importing prism-verify; runtime input traces; the matching Hasher instance; runtime outputs from verification (Certified<GroundingCertificate> or ReplayError). |
The three environments are entirely distinct. No environment hosts a Prism-operated service. No environment is required to be online, networked, or reachable from any other environment. In particular:
-
The author’s compilation environment does not need to be reachable from the user’s execution or verification environments. After the author distributes the executable, the author’s environment is no longer in the application’s execution path.
-
The user’s verification environment does not need to be reachable from the user’s execution environment. The two MAY be the same machine or process; they MAY be different machines under the user’s control; they MAY be different in time (verify days after running).
-
The distribution channel by which the executable reaches the user (ADR-004) is external to all three environments. Prism does not specify it.
Each environment is shown in its own deployment view below; the topology between them — the executable transiting from author to user, the trace flowing into verification — is the subject of the dynamic Distribute and Run scenario (chapter 6, scenario 4) and the prose above.
The three-environment topology is a direct consequence of the constraints. Each environment exists because a specific architectural property requires it:
| Environment | Motivating constraint |
|---|---|
| Author’s compilation environment | Constraint TC-04 (UORassembly bilateral compile-time enforcement) requires that the Rust toolchain compile the author’s source against prism and uor-foundation. This compilation has to happen somewhere; the author’s environment is that somewhere. |
| User’s execution environment | Constraint TC-01 (zero-cost runtime) and TC-06 (no author infrastructure) together require that the executable run on the user’s own hardware, with no remote dependency. The user’s environment is where the executable runs. |
| User’s verification environment | Constraint TC-05 (replayability without deciders or hashing) and TC-06 (no author infrastructure) together require that verification be a local operation the user performs themselves, with no remote dependency. The user’s environment hosts the verification. |
Prism does not constrain the hardware on which any of the three environments run, beyond the constraint that the Rust toolchain MUST be able to produce executables for that hardware. In practice this means:
-
Author’s compilation environment: any platform with a Rust toolchain installation. The toolchain itself targets a wide set of host platforms; Prism inherits this support without restriction.
-
User’s execution environment: any platform for which the author’s executable was built. The author selects the target at compile time; the user runs on a matching platform. Targets supported include: hosted operating systems (Linux, macOS, Windows, BSD), bare-metal embedded platforms (
thumbv7em-none-eabihfand similar), WebAssembly runtimes, and any other target the Rust toolchain emits for. The#![no_std]posture (section 8) means the foundation crates do not assume any host services beyond what the chosen target provides. -
User’s verification environment: same as the execution environment, with the additional requirement that the matching
Hasherimplementation be available on the platform. SinceHasheris a Rust trait the author selects, and the user (or third party) provides a matching implementation, the requirement is that the implementation compile for the user’s target.
The hardware envelope is therefore "anywhere Rust runs," with no
narrower restriction. This includes platforms with no allocator (the
foundation’s #![no_std] default supports them), no networking (the
foundation does not invoke networking), no filesystem (the foundation
does not invoke filesystem operations), and no operating system
(bare-metal targets are supported).
Each Infrastructure Level 1 environment decomposes into the artifacts and processes that occupy it.
| Artifact | Role |
|---|---|
| Author’s crate source | Rust source files (*.rs) and Cargo.toml. Includes the author’s ConstrainedTypeShape impls, Grounding impls, substitution-axis selections, domain logic, and any application-specific entry point. |
uor-foundation (compiled) |
The foundation crate as compiled by rustc. Either compiled fresh during the build, or retrieved from cargo's build cache. |
prism (compiled) |
The prism crate as compiled by rustc. Either compiled fresh, or cached. Contains the pipeline runtime, the seal regime, the replay machinery, the operation-declaration vocabulary, the standard type library, and the vocabulary re-exports of uor-foundation. (The shape proc-macros live in uor-foundation's internal proc-macro sub-crate, reached through prism's vocabulary re-exports — a Cargo packaging detail not exposed in the wiki.) |
| Rust toolchain |
cargo, rustc, the linker, and supporting tools. Provided by the toolchain distribution the author has installed. |
| Output executable | The compiled executable produced by the build. Targets WASM or native machine code per the author’s cargo build --target selection. |
The author runs cargo build (or equivalent invocation) in this
environment. Scenario 3 of section 6 specifies the sequence; this
Infrastructure Level 2 view names the artifacts that participate.
uor-foundation is fetched from crates.io (published from the
UOR-Foundation/UOR-Framework repository); prism and prism-verify
are fetched from crates.io (published from the UOR-Foundation/Prism
repository). Repo locality is invisible at build time; cargo resolves
both from crates.io transparently (ADR-015).
| Artifact | Role |
|---|---|
| Author’s executable | The binary the user obtained from the distribution channel. Self-contained per constraint TC-01 (zero-cost runtime); contains no Prism runtime layer. Includes the application’s selected axis impls (per the A: AxisTuple + Hasher substrate parameter per ADR-030 + ADR-036 — e.g., the prism-crypto HashAxis impl invoked type-associatedly via <A as Hasher>::initial()) and the application’s selected resolver impls (per the R: ResolverTuple substrate parameter per ADR-036 — e.g., NerveResolver / PostnikovResolver / HomotopyGroupResolver / KInvariantResolver impls in the canonical k-invariants branch per ADR-035, threaded as resolvers: &R value reference through pipeline::run_route) as monomorphized native code. Both axis and resolver dispatch is resolved by the Rust toolchain at the author’s compile time. |
| Runtime input | The data the executable processes. Source is the user’s choice — files, streams, sensor input, manual entry, network input, anything the application’s domain logic accepts. |
| Runtime output | The data the executable produces. Includes whatever the application’s domain logic surfaces: typically an output value plus, for outputs that traversed the principal data path, a Trace and a Certified<GroundingCertificate>. |
The user runs the author’s executable directly. No Prism-specific deployment process exists; the executable is a binary the user runs as they would any other application binary on their platform.
| Artifact | Role |
|---|---|
| Verification executable | A separate binary that imports prism-verify and surfaces certify_from_trace to the user (typically through a CLI, a library API call, or a UI). The executable is compiled by the user (or by a third party the user trusts) using the Rust toolchain. Distribution to the user is parallel to the author’s distribution: through any channel of the user’s choosing; Prism does not participate. |
Hasher instance |
The matching Hasher implementation, instantiated. The user provides this; its identifier MUST match the hasher_identifier in the trace under verification. |
| Trace input | The Trace value the user is verifying, deserialized from the wire format specified in section 8. |
| Verification output | Either Certified<GroundingCertificate> (verification succeeded) or ReplayError (verification failed). |
The verification environment MAY be the same machine and process as the execution environment, in which case the verification executable and the application’s executable could be the same binary (with the application performing self-verification immediately after producing each output). The architecture admits this co-location; it does not require it.
prism-verify is fetched from crates.io (published from the
UOR-Foundation/Prism repository), with prism and uor-foundation as
transitive dependencies (since prism-verify re-exports prism's
certify_from_trace and uor-foundation's wire-format types). Repo
locality is invisible at build time (ADR-015).
The mapping of Prism’s three containers to the three deployment environments:
| Container | Author’s compilation env. | User’s execution env. | User’s verification env. |
|---|---|---|---|
uor-foundation |
Present (as compiled dependency of author’s crate) | Present (linked into author’s executable: type definitions, mint primitives, kernel/primitives substrate) | Present (linked into verification executable; only the type definitions and wire-format types are pulled in, not the mint primitives or kernel substrate) |
prism |
Present (as compiled dependency of author’s crate; participates at both compile time and runtime) | Present (linked into author’s executable: the pipeline runtime IS in the executable; this is what produces sealed values at runtime) | Present (linked into verification executable; prism's replay machinery is what prism-verify re-exports as certify_from_trace) |
prism-verify |
Absent (the author does not import the verifier; the author produces traces, does not verify them) | Absent (unless the application performs self-verification, in which case the verifier appears in the user’s execution environment as a transitive dependency of the author’s crate) | Present (as compiled dependency of the verification executable; thin façade re-exporting from prism and uor-foundation) |
This mapping makes explicit that the author’s executable carries prism
and uor-foundation at runtime: the pipeline runtime is in prism, the
mint primitives and substrate are in uor-foundation, and they execute
together to produce sealed values. The verification executable carries
prism-verify (the façade), prism (the replay implementation), and
uor-foundation (the wire-format type definitions). Each environment
hosts the minimum subset of Prism’s containers necessary for its role;
the minimum for any role that produces or consumes sealed values is
uor-foundation plus prism.
The deployment topology satisfies the following normative properties:
-
No central infrastructure: No deployment environment hosts a Prism-operated service. There is no centralized verification authority, no key management server, no registry. (Constraints TC-06, ADR-003, ADR-004.)
-
Offline operation: Each environment can perform its role with no network connectivity. The author’s compilation requires only the toolchain and the crate sources; the user’s execution requires only the executable; the user’s verification requires only the verification executable, the trace, and the matching
Hasherinstance. -
Author-user temporal independence: The author’s environment can be permanently shut down after distribution without affecting the user’s ability to run the executable or verify its outputs. The author’s role ends at distribution.
-
Verification-execution temporal independence: The user can verify a
Traceat any time after the trace was produced — immediately, days later, years later. The trace and the matchingHasherare sufficient; nothing else needs to be retained. -
Hardware portability: Any platform the Rust toolchain targets can host any of the three environments. The platforms hosting the three environments need not match each other.
These properties follow from the deployment topology being a consequence of the architectural constraints, not a deployment choice that satisfies them. A different deployment topology that hosts a Prism-operated service somewhere would violate constraint TC-06; therefore the topology specified here is the only one consistent with the architecture.