Evidence, Audit, Billing, And Release Custody designed
GPUaaS already has a stronger custody model than the portal usually communicates. This page makes that explicit.
Custody Domains
| Domain | Canonical rule |
|---|---|
| Audit | privileged mutations append events; they are not a local debug log |
| Billing | money state is derived from immutable ledger facts |
| Evidence | UAT, release, security, and runtime proof are durable bundle/items, not chat summaries |
| Release | one exact SHA plus approval, rollback, and residual-risk evidence |
One-Correlated-Custody Model
The point is not that everything becomes one table. The point is that a reviewer can follow one action across custody surfaces.
What The Platform Already Enforces
| Surface | Existing posture |
|---|---|
| Audit | actor, role, target, result, correlation id, metadata |
| Evidence | bundle, item, result vocabulary, owner, retention class, invariant coverage |
| Billing | append-only ledger posture and policy-driven rating path |
| Release | exact SHA promotion with release/UAT/security/rollback proof expectations |
Why This Matters
Without this model, teams tend to describe readiness in prose. GPUaaS already has the stronger direction:
- actions produce appendable proof;
- money changes produce ledger facts;
- release posture produces one promotion packet;
- operational verification is expected to land as evidence, not just notes.
Reader Shortcuts
| Question | Best next page |
|---|---|
| how is money state defended? | Billing And Ledger |
| what belongs in a release packet? | Release Evidence |
| how do operators use this in practice? | Release Operations |
| what package shapes exist in code? | Platform Contracts for Builders |
Canonical sources