Lifecycle Technical Processes

Lifecycle: Technical Processes

This chapter specifies Prism’s instance of the Technical processes from ISO/IEC/IEEE 15288:2023 Clause 6.4. The fourteen processes in this group concern the engineering of the system itself: requirements, architecture, design, analysis, implementation, integration, verification, transition, validation, operation, maintenance, and disposal.

Note

Normative source: ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes, Third edition (2023-05). Published jointly by ISO, IEC, and IEEE; supersedes ISO/IEC/IEEE 15288:2015. ICS 35.080. Free preview at iso.org/obp. This chapter covers Clause 6.4 of the standard.

The Technical processes are where the wiki carries the densest architectural content: sections 1-12 of the arc42 specification and the conceptual model are the engineering record for Prism. This chapter cross-references those artifacts per process.

Business or mission analysis

Not applicable to Prism.

The 15288 Business or mission analysis process defines the business/mission problem or opportunity, characterizes the solution space, and determines potential solutions that could address the problem. Prism is a specified system, not a business-analyzed one: the wiki documents what Prism is, not the analysis that motivated it. The motivation is sketched in section 1’s Introduction and Goals (particularly the Downstream Consequences subsection, which names the patterns Prism’s boundary properties make available downstream), but is not specified normatively because mission analysis is the Foundation’s organizational concern, not part of Prism’s architecture.

Stakeholder needs and requirements definition

Prism’s instance: section 1’s Stakeholders subsection plus section 2 (Architecture Constraints).

The 15288 Stakeholder needs and requirements definition process defines the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholders. Prism’s stakeholders are named in section 1: the application author and the application user. The Rust toolchain is named in section 3 as an external system Prism delegates to, not a stakeholder. The stakeholder needs that drive Prism’s architecture are recorded in the Requirements Overview subsection of section 1.

The stakeholder needs are translated into normative architectural constraints in section 2 (TC-01 through TC-06), which name the properties any conforming Prism implementation MUST exhibit.

System requirements definition

Prism’s instance: section 2 (Architecture Constraints) plus the Quality Requirements in section 10.

The 15288 System requirements definition process transforms stakeholder requirements into a technical view of a system that could deliver the needed services. Prism’s system-level requirements are:

• The six technical constraints TC-01 through TC-06 (section 2).

• The three substitution axes — HostTypes, HostBounds, and the third position originally Hasher per ADR-007, generalized to AxisTuple + Hasher per ADR-030 + ADR-036 (a tuple of axis trait selections with the canonical hash axis bound — HashAxis from prism-crypto per ADR-031) — plus the fourth model-declaration substrate parameter ResolverTuple per ADR-036 (defaulting to NullResolverTuple, carrying application-provided per-value content for the eight resolver-bound ψ-Term variants per ADR-035 when the model’s verb bodies emit any), with the contracts they impose (section 2). ADR-035’s ψ-residuals discipline forbids verb-body emissions of Term::FirstAdmit, Term::AxisInvocation, and byte-comparison/concat PrimitiveOps; the canonical compiled form is the k-invariants branch ψ_1 → ψ_7 → ψ_8 → ψ_9. Per ADR-037, 14 data-shape capacity caps plus 8 ψ-stage resolver output ceilings are HostBounds associated constants; two type-system tuple-impl-table caps (MAX_AXIS_TUPLE_ARITY, MAX_RESOLVER_TUPLE_ARITY) stay foundation-vetted with explicit Rust-language carve-out. Per ADR-038 + ADR-040, the closed Observable taxonomy admits observable:AxisProjectionObservable for axis-realized admission relations; the closed BoundShape catalogue carries 7 individuals with type:LessEqBound for integer-valued observables and type:LexicographicLessEqBound for byte-sequence-valued observables (canonical big-endian unsigned ordering). Per ADR-041, the eight ψ-stage resolver traits thread typed-coordinate carriers (SimplicialComplexBytes<'a>, ChainComplexBytes<'a>, …, KInvariantsBytes<'a>) — zero-allocation #[repr(transparent)] newtypes preserving type-system discrimination of ψ-stage outputs. Per ADR-039 + ADR-042, the canonical k-invariants branch realizes the ontology’s three-primitive inhabitance verdict structure (cert:InhabitanceCertificate envelope for positive verdicts; cert:InhabitanceImpossibilityCertificate envelope with proof:InhabitanceImpossibilityWitness payload for negative verdicts; κ-label as homotopy-classification structural witness at ψ_9; concrete cert:witness ValueTuple derivable from Term::Nerve's 0-simplices at ψ_1); foundation provides typed Rust views (InhabitanceCertificate<'a, T> over &Grounded<T>; InhabitanceImpossibilityCertificate<'a> over &PipelineFailure) with accessors for the verdict-envelope coordinates and an optional inhabitance::dispatch_through_table helper for predicate:InhabitanceDispatchTable consultation.

• The three identifier conventions CV-01 through CV-03 (section 2).

• The five quality scenarios QS-01 through QS-05 (section 10), each giving a measurable acceptance criterion for a quality goal.

• The secondary quality properties enumerated in section 10.

Each requirement has a corresponding architectural artifact in sections 3-9 that satisfies it.

System architecture definition

Prism’s instance: sections 3, 4, and 5 (Context and Scope, Solution Strategy, Building Block View).

The 15288 System architecture definition process generates system architecture alternatives, selects one, and expresses this in a set of consistent views. Prism’s architecture is documented through arc42 sections 3 and 5, which together provide the static views at three levels of decomposition:

• Context and Scope (section 3): Prism as one logical entity interacting with three external actors (application author, application user, Rust toolchain).

• Building Block View, "Whitebox Overall System" (section 5): Prism opens into three containers (uor-foundation, prism, prism-verify).

• Building Block View, "Level 2" and "Level 3" subsections (section 5): each container opens into components, and components whose internal structure is architecturally significant open further.

The architecture is one specific solution; alternatives are recorded in the relevant ADRs (section 9). ADR-005 (decompose Prism into three crates), ADR-006 (compile-time UORassembly enforcement), ADR-007 (substitution axes allocation), ADR-011 (sealing via Rust visibility rules), and ADR-024 (three-layer algebraic closure: substrate, prism, implementation; the spine that ADR-025 and ADR-026 attach the operator-set commitments to) are the load-bearing architectural decisions.

Design definition

Prism’s instance: section 5 (Building Block View, components and their internals) and section 8 (Cross-cutting Concepts).

The 15288 Design definition process provides sufficient detailed design information about a system and its elements to enable the implementation. Prism’s design definition is split between:

• The component-level structure of each container, given by chapter 5’s "Level 2" subsection: uor-foundation's components (enforcement, mint primitives, bridge, kernel, primitives, user, the shape proc-macros), prism's components (pipeline, seal regime, replay, vocabulary re-exports, the operation-declaration vocabulary, the standard type library), and prism-verify's re-export facade. Component internals architecturally significant beyond their interface are given by section 5’s "Level 3" subsection.

• The cross-cutting concepts that span components (section 8): the trace wire format, the certificate format, the hashing substrate contract, the substitution axes' contracts, the seal regime, the operation-declaration vocabulary, the closure property, the principal data path’s stage transitions, the three-layer algebraic closure (substrate / prism / implementation, ADR-024), the substrate operator set (ADR-025) and prism operator set (ADR-026), the catamorphism’s per-variant evaluation semantics (ADR-029), and the typed-iso surface’s value-payload carriership (ADR-027 + ADR-028).

The design is normative at both levels. An implementation that diverges from the wire formats or the seal regime is not conformant.

System analysis

Prism’s instance: section 6 (Runtime View) plus section 8’s specifications of dynamic behavior.

The 15288 System analysis process provides a rigorous basis of data and information for technical understanding to aid decision making across the life cycle. Prism’s system analysis is documented as four runtime scenarios in section 6: Principal Data Path Execution, Trace-Replay Verification, Compile-Time UORassembly Enforcement, and Distribute and Run. Each scenario specifies the sequence of interactions, the properties that hold during the scenario, and the constraints (TC-01 through TC-06) the scenario satisfies.

The analysis is normative: a conforming implementation MUST exhibit the behavior each scenario describes. Deviation in scenario sequence or in the named properties is non-conformance.

Implementation

Prism’s instance: the source code of uor-foundation, prism, and prism-verify.

The 15288 Implementation process realizes a specified system element. Prism’s implementation is the three Rust crates published from UOR-Foundation/UOR-Framework (uor-foundation) and UOR-Foundation/Prism (prism, prism-verify). The wiki specifies the implementation’s intended structure; the codebase realizes it. Cross-references between the wiki and the codebase use the wiki’s identifier discipline (constraint CV-02): when the wiki names a component, type, trait, function, or module, it uses the identifier from the codebase verbatim, in monospace, without prose paraphrase.

The implementation honors the wiki’s normative properties through:

• Sealed types in two crates (Datum, Triad, Derivation, FreeRank in uor-foundation; Validated, Grounded, Certified in prism), constructed only through the principal data path (constraint TC-02, ADR-011, ADR-016).

• The mint primitives reserving cross-crate construction of the four UOR-domain sealed types to prism's pipeline by architectural commitment (ADR-016).

• Bilateral compile-time bounds against uor-foundation and the application author’s crate (constraint TC-04, ADR-006).

Integration

Prism’s instance: the UORassembly contract and the closure property.

The 15288 Integration process synthesizes a set of system elements into a realized system that satisfies system requirements, architecture, and design. Prism’s three crates are integrated into a single executable by the Rust toolchain at compile time. The integration mechanisms are:

• UORassembly (section 8 and ADR-006): the bilateral compile-time contract that uor-foundation MUST satisfy prism's bounds and the application author’s crate MUST satisfy prism's exposed surface. Failure of either side fails compilation.

• Closure under uor-foundation (ADR-013): every type prism exposes derives from uor-foundation's type-declaration vocabulary; every operation declaration composes uor-foundation::PrimitiveOp discriminants. The closure means integration is monolithic at the vocabulary level even though the crates are separately published.

• prism's vocabulary re-exports: the application author imports only prism and reaches uor-foundation's surface through it. Integration at the author’s import boundary is through a single crate.

The result of integration is the application author’s compiled executable, which contains prism's pipeline runtime, uor-foundation's mint primitives and type definitions, and the author’s domain code, linked together as native code by rustc. No runtime integration step exists; integration completes at compile time.

Verification

Prism’s instance: the wiki’s validator scripts plus the codebase’s cargo test, lake build, and conformance suite — prism as the V agent in the structural V/IV&V split (ADR-021).

The 15288 Verification process provides objective evidence that a system or system element fulfills its specified requirements and characteristics. Prism’s verification is layered:

• The wiki’s validator scripts verify that the wiki itself conforms to its three coordinated standards (arc42+C4, OPM ISO 19450, ISO/IEC/IEEE 15288).

• The codebase’s cargo test verifies that the rustdoc-claimed behaviors hold (each architectural claim has an executable doctest).

• The Lean library (lake build) verifies that the wiki’s mathematical claims hold under a zero-sorry discipline. Lean is the formal artifact for the external referent — the published UOR Foundation mathematics that validation is ultimately measured against (ADR-021, Decision 2).

• The conformance suite verifies end-to-end behavioral claims (pipeline replay equivalence, certificate idempotence, hasher contract conformance).

Verification is mechanical and reproducible: every artifact is either passing or failing the relevant gate, with no human judgment absorbing ambiguity. The wiki cross-references the codebase’s verification artifacts by source-side identifier; a reviewer reads the wiki and the codebase together to confirm the artifact exists and says what the wiki claims it says.

The prism runtime is the catamorphism direction of the hylomorphism (section 8, Foundation as a Signature Category): it produces sealed Grounded<T> from foundation-vocabulary routes. The V activity verifies that prism's catamorphism is correct against the term-language semantics (initiality + uniqueness; ADR-019) and that the per-variant fold-rules are conformant per ADR-029 (the normative evaluation semantics that turn Term-shaped input into carrier-shaped output by induction on Term structure). The substrate operator set (ADR-025) and prism operator set (ADR-026) provide additional conformance test vectors: catalog and transition tables at any committed snapshot enumerate algebra-level predictions whose agreement across implementations is layer-1 V activity; the closure of routes under the seven prism operators (ADR-026) plus the foundation primitives is checked at the macro’s FoundationClosed impl emission. The IV&V activity (Validation, below) verifies the dual direction.

Transition

Not applicable to Prism.

The 15288 Transition process establishes a capability for a system to provide services in its operational environment. Prism is a library distribution; there is no operational environment Prism transitions into. The application author’s executable, once compiled, runs in the application user’s execution environment without any transition step that Prism specifies. Constraint TC-06 (no application-author infrastructure) precludes any transition process that would require ongoing author involvement.

The Rust toolchain’s compilation of the executable is not a transition in the 15288 sense; it is the implementation step (above) producing the artifact that the user runs.

Validation

Prism’s instance: prism-verify (the replay surface) and constraint TC-05 — prism-verify as the IV&V agent in the structural V/IV&V split (ADR-021).

The 15288 Validation process provides objective evidence that the system, when in use, fulfills its business or mission objectives and stakeholder requirements, achieving its intended use in its intended operational environment. Prism’s validation is a first-class architectural concern: every produced Grounded<T> is accompanied by a Trace (constraint TC-05), and the application user (or any third party they trust) validates the produced output by invoking prism-verify::certify_from_trace against the trace and the matching Hasher.

The validation is local-by-construction (ADR-003): the user’s verification environment requires no service from the application author and no cryptographic hash function invocation (the fingerprint is data carried by the trace). The validation surface is minimal: a Trace, a Hasher instance, and a Certified return type. The implementation lives in prism's replay component; prism-verify is the facade re-exporting it.

prism-verify is the anamorphism direction of the hylomorphism (section 8, Foundation as a Signature Category): it produces Certified<GroundingCertificate> by walking the Trace structurally, without re-evaluating the application author’s deciders or invoking any cryptographic hasher beyond identifier matching. This is independence-by-construction — the IV&V agent cannot cheat by re-running the catamorphism, because the anamorphism’s contract is to walk the trace’s typed derivation steps. The trace is the artifact crossing the V/IV&V boundary (ADR-021, Decision 3); it is the internal validation referent governing implementation reproducibility (ADR-021, Decision 2), distinct from the external referent (the published UOR Foundation mathematics) that governs spec faithfulness.

The round-trip property — every Grounded<T> produced by pipeline::run MUST replay through prism-verify::certify_from_trace to a Certified<GroundingCertificate> — is normative under ADR-021 (Decision 2). It is an IEEE 1012 V&V activity, not a behavior-test fixture: a Prism implementation that cannot demonstrate round-trip closure on every produced Grounded<T> is non-conforming. The conformance suite (cargo run --bin uor-conformance) exercises the round-trip on the standard test corpus; an application’s V&V plan exercises it on the application’s own production corpus per the consumer-class IL band (ADR-021, Decision 4).

Operation

Prism’s instance: the application user’s execution environment (section 7, Deployment View).

The 15288 Operation process uses the system to deliver its services. Prism’s operation is the application user running the application author’s executable on local hardware. The execution environment requires no service operated by the author (constraint TC-06); no cloud, server, or network resource Prism specifies must be available. The user’s hardware is the operating environment.

The executable carries prism's pipeline runtime as compiled code, plus uor-foundation's mint primitives and type definitions. At runtime, no Prism runtime layer mediates the function call into pipeline::run (constraint TC-01); the executable runs at full hardware speed. The pipeline runtime cost beyond uor-foundation's contribution is bounded and quantified in section 10 (Quality Requirements).

Maintenance

Prism’s instance: the wiki’s pin-update discipline plus the codebase’s amendment cadence (ADR-014’s operation declaration vs. operation shipment principle).

The 15288 Maintenance process sustains the capability of the system to provide a service. Prism’s maintenance is twofold:

• Wiki maintenance: pin updates (the arc42-generator submodule, the structurizr.war checksum, the cmark-gfm tag, the gem versions, the three transcribed-standard pin files) are deliberate maintainer acts performed by direct push. Each pin update is co-committed with the regenerated wiki output so the wiki’s rebuild from sources remains deterministic.

• Codebase maintenance: amendments to uor-foundation cascade to prism through the bilateral UORassembly bounds; amendments to prism cascade to the application author’s crate through the exposed surface. The amendment cadence is governed by ADR-014 (operation declaration vs. operation shipment): prism ships the vocabulary, the application author writes operation declarations in that vocabulary, and the toolchain enforces well-typedness. New primitive operations require an amendment to uor-foundation's PrimitiveOp enum (closure under uor-foundation, ADR-013); new operation declarations require no amendment to either crate.

The maintenance cadence is governed by semver discipline: minor version bumps of uor-foundation and prism are non-breaking; major version bumps are breaking. The wiki’s pin to specific crate versions in the arc42 chapters' descriptive prose is implicit (the wiki names current behavior, not version-specific history).

Disposal

Not applicable to Prism.

The 15288 Disposal process ends the existence of a system entity for its intended use, appropriately handles replaced or retired elements, and properly attends to identified critical disposal needs. Prism executables run independently of any infrastructure; there is no decommissioning step the system requires. The application user retains or discards the executable at their own discretion through ordinary file-system mechanisms; Prism does not specify any disposal procedure.

The application author’s act of un-publishing a crate from crates.io is an organizational matter external to Prism. The existing executables in users' hands continue to function; their operation does not depend on the crate remaining published (constraint TC-06 again). Verification of previously-issued traces continues to function as long as the user retains the matching Hasher selection identifier and a prism-verify distribution.