# 3.16 Output Classes

### 3.16 Output Classes, Reliance Classes, and Admissibility Posture

#### 3.16.1 The governing proposition

Nexus does not treat artifacts as documents in the ordinary administrative sense. It treats them as governance objects with defined purpose, sequence position, authority relation, reliance boundary, handling condition, correction pathway, and interoperability role. A pack is never merely “a pack.” An annex is never merely “an annex.” A summary is never merely “a summary.” Each object exists inside a controlled constitutional taxonomy, and its meaning depends on what class of output it is, what stage of the operating sequence it belongs to, what reliance it may properly bear, and what admissibility posture it has genuinely earned.

This section therefore establishes three linked disciplines at the center of the governance-facing and finance-facing artifact system. **Output class** answers what kind of object an artifact is and where it sits in the sequence. **Reliance class** answers what kind of use and dependence may properly be placed on it. **Admissibility posture** answers how, where, and under what level of scrutiny it may be used in public, sovereign, institutional, finance-facing, or controlled-review environments. Together, these disciplines determine not only what an artifact is, but what the ecosystem is allowed to do with it.

#### 3.16.2 Why artifact taxonomy is constitutionally necessary

A category as complex as Nexus cannot rely on generic labels such as memo, brief, annex, deck, note, pack, or dossier. Those labels are too weak to carry constitutional meaning. The architecture already requires that maturity, routeability, comparability, finance-readiness, portability, and bounded authority claims attach only to the correct underlying artifacts, under the correct records-valid conditions, and within the correct stage discipline. That requirement cannot survive if artifact taxonomy remains casual.

Artifact taxonomy is therefore constitutionally necessary because it prevents force from migrating into whichever object happens to be shortest, most polished, most circulated, or most commercially useful. It preserves the distinction between preparation and determination, between diligence support and commitment, between packaging and execution, between public-safe communication and stronger source record, and between routeability support and execution-side legal effect. A proof pack is not merely an evidence file. A verification annex is not merely a technical note. A readiness scorecard is not merely a dashboard slide. A public-safe summary is not the underlying object itself.

Without controlled taxonomy, the architecture would remain vulnerable to exactly the forms of stage inflation and semantic borrowing already prohibited in the prior sections. With controlled taxonomy, the system gains a more durable constitutional property: it becomes harder to manipulate by formatting, audience, or repetition alone.

#### 3.16.3 Output class as the first discipline

Output class is the first discipline because the system must know what an object is before it can say how much anyone may rely on it. Output class identifies the constitutional-operating nature of the artifact. It establishes the artifact’s native position in the sequence, its relation to authority, the stronger objects it depends on, the weaker objects it may generate, and the range of claims it is capable of supporting without distortion.

An output class therefore determines, at minimum:

a) what stage of the operating sequence the artifact belongs to;\
b) what kind of authority surface it presupposes, reflects, or records;\
c) what downstream readers may legitimately infer from its existence;\
d) what stronger source objects govern it;\
e) what later-stage artifacts it may support without becoming them.

This is why output class comes before reliance class. Reliance cannot be truthfully assigned to an object whose constitutional identity is still vague.

#### 3.16.4 Why output class must remain visible, not merely inferable

A hidden artifact taxonomy is only marginally better than no taxonomy. In a high-consequence system, class must be visible enough that a reader, reviewer, or downstream actor does not need insider context to know what kind of object is in hand. If class is left to implication, then seriousness of audience, visual polish, or institutional prestige will inevitably begin to substitute for proper classification.

Nexus therefore requires that output class be legible in the artifact itself, in its metadata, record position, handling posture, and where relevant in its cover logic and controlled-room presentation. The system must not rely on “everyone knows what this really is.” That is precisely the kind of ambient understanding that validity-by-record was designed to replace.

#### 3.16.5 The primary output families

The architecture recognizes a structured output universe rather than one flattened document universe. At minimum, the primary output families are as follows.

First are **signal-bearing artifacts**, including intake logs, signal notices, watch entries, threshold flags, and triage triggers.

Second are **evidence-bearing artifacts**, including evidence packs, source registers, lineage and provenance forms, uncertainty disclosures, analytical notes, safeguarded intelligence bundles, and related evidentiary structures.

Third are **determination-bearing artifacts**, including recorded determinations, classifications, committee dispositions, holds, priority records, and other governance-valid decision objects.

Fourth are **readiness artifacts**, including work packages, readiness scorecards, capability activation records, routeability preparation notes, pathway-build modules, precondition maps, and structured readiness actions.

Fifth are **proof and finance-facing artifacts**, including proof packs, verification annexes, covenant modules, settlement specifications in readiness form, compliance-routing modules, and related diligence-compression objects.

Sixth are **routing artifacts**, including interface dockets, controlled transmittal packs, diligence-room dossiers, counterpart-ready controlled packs, and audience-specific routing summaries.

Seventh are **monitoring, correction, and learning artifacts**, including correction notices, re-issue packages, redistribution reconciliation logs, drift-event notices, after-action reviews, and structured learning records.

These families are not merely functional labels. They are separate constitutional-operating species because different kinds of truth, force, risk, and boundary discipline attach to each.

#### 3.16.6 Why the system needs distinct artifact families rather than one modular pack

There is a recurring temptation in ambitious architectures to create one master “pack” format into which every object can be poured and then tailored by audience. Nexus rejects that simplification because it would obscure the difference between signal and evidence, evidence and determination, determination and readiness, readiness and routeability, routeability and execution-facing interface. A single flattened pack logic would encourage semantic borrowing by design.

Distinct artifact families preserve stage truth. They also preserve accountability. If an artifact is misused, the system can identify whether the problem lies in evidence sufficiency, determination quality, readiness incompleteness, packaging inflation, routing overreach, or monitoring failure. A flattened artifact ecology would make such diagnosis much harder and would encourage institutions to borrow force from the most prestigious-looking form available.

#### 3.16.7 Readiness artifacts in their strongest definition

A readiness artifact is any artifact whose principal function is to move a matter from evidence-bearing or determination-bearing state into a structured condition suitable for routeability, comparability, multilateral interface, sovereign review, or finance-facing review, without crossing into execution. Readiness artifacts are not weak because they are pre-routing. They are among the most strategically valuable objects in the architecture because they are the disciplined bridge between governance-valid internal meaning and externally legible pathway structure.

Typical readiness artifacts include:

a) work packages;\
b) pathway-build modules;\
c) readiness scorecards;\
d) capability activation records;\
e) routeability preparation notes;\
f) structured precondition maps;\
g) host and lifecycle readiness matrices.

Their function is to establish technical, governance, host, support, lifecycle, reserve, safeguards, and route preconditions before proof-pack and routing artifacts are formed. Their danger is that they may be overread as proof of finance-facing completion when they are only establishing the conditions under which later-stage claims may truthfully arise.

#### 3.16.8 Why readiness artifacts are structurally powerful but still bounded

The architecture deliberately treats readiness artifacts as powerful because real pathways are built here. This is the stage at which the system becomes operationally serious. But readiness artifacts remain bounded because they do not create routeability merely by being highly structured, and they do not create financing, procurement, underwriting, sovereign appropriation, issuance, or settlement merely by being persuasive.

This is one of the most important constitutional tensions in the artifact system. Nexus solves it by giving readiness artifacts real dignity without letting them borrow later-stage force. That is a more mature design than either of the common alternatives: underbuilding readiness because it is “not yet finance,” or overstating readiness because it is “almost finance.”

#### 3.16.9 Proof packs as the primary finance-facing readiness artifact

The proof pack is the primary finance-facing readiness artifact of Nexus. Its purpose is to convert governance-valid, readiness-bearing output into a disciplined diligence object that compresses review time, preserves lawful basis, states uncertainty, protects safeguards, supports comparability, and establishes bounded routeability without collapsing into execution. A proof pack is modular, case-bound, versioned, distribution-logged, correctionable, finance-facing, and still governance-bounded.

It exists because the routeability threshold has genuinely been crossed. It does not exist to create the appearance of maturity before that threshold is reached. A proof pack that is visually sophisticated but semantically ambiguous is defective. A proof pack that is commercially attractive but constitutionally inflationary is invalid. A proof pack that omits mandatory substance while compensating with presentation is not merely incomplete. It is architecture-breaking because it invites readers to rely on form where substance is missing.

#### 3.16.10 Why proof packs are not generic and must remain lane-specific

Proof packs are not one generic artifact flattened across all pathways. Sovereign-facing packs, public-purpose budget packs, commercial credit packs, insurance-facing packs, guarantee packs, DFI/MDB packs, corridor continuity packs, and operator-resilience packs may share a common structural spine, but they do not erase real differences in downstream burden, legal environment, review logic, or route structure.

Lane-specific proof-pack design is therefore not inefficiency. It is a truth discipline. It allows industrialization of readiness quality without pretending that all downstream actors need the same assurances, the same form of lawful-basis logic, or the same module set. Nexus becomes more credible precisely because it rejects false standardization where pathway burdens are materially different.

#### 3.16.11 Minimum proof-pack structure

Minimum proof-pack structure is part of admissibility, not a design preference. A proof pack must contain enough matter to justify its class and enough boundary discipline to prevent false inference. At minimum, that structure should include:

a) controlled cover and identity metadata;\
b) executive statement of what is and is not asserted;\
c) authority and lawful-basis positioning;\
d) program, asset, pathway, host, or corridor description;\
e) routeability summary with explicit boundaries;\
f) evidence-module index and provenance structure;\
g) data-lineage and integrity note;\
h) uncertainty and assumption disclosure;\
i) verification annex or formal annex reference;\
j) covenant and monitoring architecture where relevant;\
k) safeguards and do-no-harm position;\
l) market-sensitivity and conduct note where relevant;\
m) compliance-routing note where relevant;\
n) correction, redistribution, and re-issue logic.

Additional modules may be required by lane, including escrow logic, waterfall logic, payout-interface logic, ratings-interface logic, sovereign restriction logic, or public-finance condition logic. This structure exists to prevent pack inflation, meaning the creation of impressive-looking finance-facing objects that do not actually disclose lawful basis, uncertainty, lineage, or correction posture.

#### 3.16.12 Verification annexes in their strongest definition

A verification annex is a standardized attachment that translates a proof-bearing matter into a testable, monitorable, dispute-aware, settlement-compatible, and routable structure by specifying triggers, sources, steps, roles, uncertainty posture, review clocks, dispute boundaries, and interface instructions. It is the artifact through which trigger logic, validation method, test conditions, review clocks, and bounded interface logic become explicit and portable.

Its role is tightly bounded. A verification annex does not, by itself, create payout entitlement, financing availability, sovereign obligation, procurement mandate, or legal enforceability. It makes later lawful acts more structured. It does not become those acts merely because it is technically rigorous. This is why verification annexes are powerful and easy to misread. The architecture must therefore keep their class exceptionally clear.

#### 3.16.13 Monitoring packs, covenant notes, and observability artifacts

Monitoring packs, covenant architecture notes, telemetry packs, and observability artifacts occupy a related but distinct family position. Their role is to define telemetry fields, cadence, variance logic, threshold triggers, monitoring expectations, compliance posture, breach indicators, refresh obligations, and correction conditions after or alongside routing. They help preserve pathway integrity through time. They do not by default create servicing, fiduciary monitoring, claims administration, sovereign disbursement duty, or binding covenant effect unless and until lawful downstream actors explicitly incorporate them into their own controlled environments.

This distinction matters because the architecture seeks not only to package readiness for first review, but to preserve route and performance truth after review. Monitoring artifacts therefore matter greatly. Their importance does not justify semantic overreach.

#### 3.16.14 Diligence-room packs and controlled review posture

A diligence-room pack is a controlled artifact environment assembled for authorized review by bounded external readers. It is not a generic repository. It is a controlled derivative environment built from the same canonical evidence and proof spine as the upstream artifact system and therefore remains subject to:

a) stage truth;\
b) artifact class truth;\
c) reliance-class limits;\
d) handling and distribution control;\
e) version and supersession discipline;\
f) correction and re-issue capability.

Entry into a diligence room does not upgrade an artifact’s constitutional force. Use in a controlled room does not by itself raise admissibility posture. External seriousness does not cure internal incompleteness. This is one of the architecture’s most important anti-inflation rules.

#### 3.16.15 Counterparty-interface and handoff artifacts

Counterparty-interface packs, qualification briefs, transmittal memoranda, and handoff artifacts form another major output family. Their role is to translate route-bearing matters into the decision surface of a particular class of downstream reader while preserving explicit boundary at the point where authority, liability, review burden, or control transfers.

These artifacts are routing artifacts or handoff artifacts, not execution documents. They exist to make interface disciplined. They do not create booking, mandate, commitment, or downstream legal completion simply by existing. Their value lies in reducing ambiguity for the receiving actor, not in letting the governance core narrate itself as already beyond governance.

#### 3.16.16 Public-safe summaries and derivative artifacts

Public-safe summaries and derivative extracts are necessary because the ecosystem must communicate across audiences with different handling rights, technical depth, and decision needs. But they remain derivative artifacts and must be treated accordingly. A public-safe summary is typically low-force, narrowed, audience-specific, and defaulted toward informational or bounded decision-support posture. Its main risk is that it may be treated as the full artifact.

The architecture therefore requires that derivative artifacts remain semantically subordinate to their stronger sources. They may narrow, summarize, and render safe. They may not widen, upgrade, or reclassify. This rule is not merely about communications hygiene. In complex systems, the shortest artifact often becomes the most circulated, and the most circulated artifact often becomes the practical constitution unless strong derivative discipline prevents it.

#### 3.16.17 Reliance class in its strongest definition

Reliance class is the degree and type of dependence that may properly be placed on an artifact by governance bodies, sovereign or public readers, capital-facing actors, runtime bodies, or licensed downstream participants. Output class answers what the object is. Reliance class answers what kind of action, review, or expectation it may properly support.

This discipline is crucial because the same broad artifact family may be encountered by actors with radically different functions. A national council, a regional support body, a DFI, a private insurer, a sovereign treasury, a bank committee, and a licensed downstream operator may all encounter one underlying matter. Reliance class prevents one reader’s seriousness from becoming another reader’s false implication.

#### 3.16.18 R1 — informational only

R1 is informational only. An R1 artifact may provide orientation, context, bounded explanation, visibility, or narrative framing. It is not fit to support binding or reliance-sensitive action and must not be used as the sole basis for determination, underwriting, settlement, route completion, or public-status inference. Public-safe summaries, contextual briefs, high-level notes, and certain explanatory extracts commonly fall here.

R1 matters because the architecture needs a legitimate low-force mode. Not every useful object should be pressured into higher-force classes. By preserving an honest informational class, the system reduces the temptation to inflate weaker artifacts merely to make them appear consequential.

#### 3.16.19 R2 — decision support

R2 is decision support. An R2 artifact may support governance judgment, committee review, internal risk consideration, sovereign review, multilateral review, diligence support, readiness assessment, or routeability assessment. It may be highly consequential. It is not by itself sufficient as sole settlement basis, and it does not become execution-effective merely by seriousness or use before serious audiences.

Many of the architecture’s most important artifacts live here: evidence packs, determination records for many uses, readiness scorecards, pathway-build notes, many proof packs, many monitoring artifacts, and many interface-support objects. R2 is therefore the core seriousness class of the governance and routeability architecture. It is where most real intellectual and institutional work occurs. The architecture protects this class from both inflation and dismissal.

#### 3.16.20 R3 — settlement-relevant or contract-ready module

R3 is the strongest reliance class recognized within the governance-produced artifact perimeter. An R3 artifact or module has reached the quality, validity, and boundary discipline necessary to be incorporated, referenced, or consumed in a settlement, covenant, trigger, calculation, or execution interface by lawful downstream actors, subject to applicable law and contract. But even here the architecture remains exact: an R3 module remains governance-produced or governance-controlled unless and until a licensed or competent downstream actor lawfully incorporates it into execution documents or execution systems.

This is one of the most important narrow-reading rules in the entire whitepaper. R3 is strong. It is not a hidden offering document, not a hidden underwriting act, not a hidden sovereign obligation, and not a hidden settlement instrument. The class is designed to support execution-side incorporation, not to smuggle execution upstream into the governance-only core.

#### 3.16.21 Why reliance class must never be inferred from polish or audience

Reliance class is not inferred from appearance, prestige, circulation, or external audience. It is not upgraded because a document looks transaction-grade. It is not upgraded because it sits in a diligence room. It is not upgraded because a sovereign or finance actor is reading it. It is not upgraded because an important sponsor, investor, or partner finds it compelling. Reliance class is earned through class, stage, authority condition, evidence sufficiency, records-validity, and gate discipline.

This rule is essential because without it the most attractive artifact would always become the strongest artifact by implication. Nexus refuses that aesthetic and institutional shortcut.

#### 3.16.22 Admissibility posture in its strongest definition

Admissibility posture determines how an artifact may be used under scrutiny in institutional, sovereign, public-purpose, or finance-facing environments. If reliance class answers how much dependence may properly be placed on an object, admissibility posture answers in what kind of review environment, under what kind of scrutiny, and with what consequence sensitivity the object may properly be used.

This is important because two artifacts may share a reliance class and still differ materially in admissibility. One may be fit for internal committee use but not for finance-facing controlled review. Another may be fit for controlled external diligence but not for settlement-reliable posture. Admissibility is therefore the ecosystem’s environment-sensitive truth discipline.

#### 3.16.23 Core admissibility postures

The architecture recognizes three principal admissibility postures.

An artifact is **informational-only admissible** where its role is explanatory, contextual, or visibility-oriented and it is not fit to support binding or reliance-sensitive action.

An artifact is **decision-support admissible** where it is adequate for governance judgment, internal decision-making, underwriting review, multilateral review, risk consideration, routeability assessment, or other bounded evaluative use but is not sufficient as sole settlement basis.

An artifact is **settlement-reliable admissible** only where it is eligible to anchor triggers, conditions precedent, covenant enforcement, calculation, or settlement logic, subject to lawful incorporation and satisfaction of the relevant gate conditions.

These postures are not labels of convenience. They are earned positions in the gate architecture.

#### 3.16.24 The rule of no over-admissibility

No actor may label an artifact settlement-reliable merely because it is detailed, attractive to a downstream counterparty, or located in a finance-facing environment. No use in a controlled room, no external seriousness, no polished formatting, and no commercial urgency may raise admissibility posture by implication. Admissibility is earned through evidence sufficiency, class discipline, version and correction discipline, reliance truth, and gate completion.

This is one of the strongest protections in the entire artifact system. It prevents over-admissibility, meaning the quiet tendency for artifacts to acquire stronger practical effect than the architecture has actually granted them.

#### 3.16.25 Artifact-before-claim and artifact-before-audience

Two operating rules follow directly from everything above.

First is the **artifact-before-claim** rule. No maturity, routeability, comparability, finance-readiness, portability, sovereignty-compatibility, or execution-adjacent claim may be made unless the underlying artifact class necessary to support that claim exists, is validly recorded, and is properly handled.

Second is the **artifact-before-audience** rule. The audience to whom an artifact is shown does not determine its class, its reliance posture, or its admissibility. A proof pack shown to a bank remains a proof pack. A routeability note shown to a sovereign remains a routeability note. A safe summary shown to investors remains a derivative summary. Audience may affect handling and formatting. It does not change constitutional meaning.

These rules are among the practical anchors of the anti-borrowing doctrine established in the previous section.

#### 3.16.26 Crosswalk to execution documents

The architecture requires a strict crosswalk between governance artifacts and execution documents. Governance artifacts include proof packs, verification annexes, monitoring architectures, dispute clocks, attestation forms, and routeability modules. Execution documents include term sheets, offering materials, insurance policies, underwriting instruments, custody documents, settlement agreements, and other documents controlled by licensed actors under applicable law.

The purpose of the crosswalk is not to keep these worlds apart absolutely. It is to keep them truthful. Governance artifacts are designed to support disclosure integrity, diligence compression, and readiness quality. They do not, by default, create execution liability, licensed obligation, or sovereign legal effect unless explicitly incorporated into lawful downstream instruments with defined scope. This distinction is indispensable to the governance-only perimeter.

#### 3.16.27 Institutional ownership across the artifact system

The artifact system is resilient partly because ownership of its disciplines is distributed rather than collapsed.

GCRI carries evidence-integrity standards, methodological sufficiency, uncertainty discipline, and evidence-bearing artifact quality.

GRF carries artifact taxonomy, comparability semantics, admissibility semantics, classification integrity, and conformance-related truth about what an object may claim.

GRA carries finance-facing packaging architecture, routeability structuring, proof-pack discipline for finance use, and execution-interface readiness design.

The Protocol Authority carries technical-validity and machine-enforceable artifact entitlements where artifact state affects technical routing, access, or role-key control.

The Records and Register Function carries authoritative capture, version history, supersession lineage, distribution logging, and correction integrity.

Safeguards and integrity functions carry the protected-participation, do-no-harm, grievance, and harm-sensitive constraints embedded into the artifact system.

This distribution of ownership prevents any one actor from monopolizing the whole truth chain.

#### 3.16.28 Strategic conclusion

Output classes, reliance classes, and admissibility posture together form the discipline by which Nexus makes artifacts legible, bounded, and safe under real scrutiny. Output class tells the system what the artifact is. Reliance class tells it what kind of dependence that artifact may support. Admissibility posture tells it how and where the artifact may properly be used under sovereign, public, institutional, financial, or controlled-review conditions. The architecture then adds a further discipline: no artifact may claim more than its class, stage, reliance posture, admissibility, and record support allow. No object may be silently compressed into another. No finance-facing object may become execution-effective merely by being detailed, serious, or widely circulated.

This is one of the deepest reasons Nexus can speak credibly to sovereigns, hosts, public authorities, banks, insurers, DFIs, operators, and licensed downstream actors without losing constitutional honesty. It does not flatten all artifacts into one ambiguous pack. It creates a rigorous object language for readiness itself.

#### 3.16.29 Closing formulation of output classes, reliance classes, and admissibility posture

Output classes, reliance classes, and admissibility posture may therefore be stated in one integrated formulation: Nexus classifies every materially consequential artifact according to what constitutional-operating object it is, what kind of dependence it may properly support, and in what scrutiny environment it may properly be used, and prohibits any artifact from being circulated, marketed, relied upon, or inferred beyond the force permitted by its class, stage, authority condition, gate status, version posture, and record support.

This is how the ecosystem becomes increasingly finance-legible, sovereign-legible, and counterparty-legible without becoming structurally inflationary. It knows what each artifact is, what it is not, and what must still happen before lawful downstream consequence can arise.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/acceleration/nexus-compute/iii.-doctrine/3.16-output-classes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.