# Workload administration and certification evidence

Status: `VERIFIED_PARTIAL`

This page explains how agents, operators, and reviewers must interpret the
workload administration evidence chain. It is an evidence-inspection contract,
not an authorization to publish, install policy, route traffic, arm Canary, or
arm Enforce.

The authenticated workload-admin implementation merged through
[cubie-tf PR #1263](https://github.com/iamdatanick/cubie-tf/pull/1263) as merge
commit `d05607bfef93220dd4cfed7499f824d1164cddce` from final PR head
`ac9b90d202b356cf699eb4b86b69efe1a4747c6c`. This establishes merged source,
not deployment. Until a deployed gateway is independently verified, do not
claim the control surface is available on a production gateway.

## What the control surface is for

The proposed `/dashboard` workload-admin panel is a read/compute-only view over
the active gateway process. It is designed to:

- inspect the canonical embedded JSON-LD workload ontology;
- inspect embedded proof bundles and their recorded verifier receipts;
- recompile the exact active signed sticker with the shipping compiler;
- compare canonical relations, the program hash, and the compile receipt;
- display the certified lower bound (`k_lower`), emitted shards, program hash,
  and independent verifier result;
- run a non-mutating evaluation of seven hypothetical compiled inputs;
- read the current Registry projection for CUB-3211 through CUB-3217;
- compare the Registry source head with the live GitHub `main` head; and
- return a server-generated, downloadable diagnostic snapshot.

It must not write to the Registry, trigger a workflow, install a sticker, alter
traffic, mutate policy, or grant release/Canary/Enforce authorization.

## The chain and its boundaries

```text
canonical JSON-LD ontology
        |
        v
shipping sticker compiler ---- embedded compiler proof bundle
        |
        v
signed sticker run manifest
        |
        v
verified active sticker program
        |
        +---- compiler replay and hash/receipt comparison
        |
        +---- advisory simulation of hypothetical compiled inputs

central CUB Registry ----------- public declaration/read-back lane
runtime request receipt -------- observed runtime-consumption lane
owner/external verifier -------- release-authorization lane
```

These lanes corroborate different facts. They are not interchangeable.

| Evidence lane | What it can establish | What it cannot establish |
|---|---|---|
| Merged source | A change is present on a named Git commit. | Deployment, Registry publication, or runtime invocation. |
| Registry publication | A generated Registry snapshot declared CUB status, wiring, and consumption metadata. | That the local gateway binary invoked a CUB for this request. |
| Public read-back | The public projection currently returns a digest, source heads, and CUB records. | Exact source identity when a source head is abbreviated. |
| Binary embedded receipt | The running binary validates embedded artifact hashes and recorded proof receipts. | Fresh execution of Lean, Coq, or Verus. |
| Runtime observed consumption | A request-bound runtime receipt records the local consumer and proof-bundle digest. | Independent formal re-verification or owner authorization. |
| External exact-head certification | An independent verifier completed the required checks at one full commit SHA. | Authorization to arm unless the owner approval contract also passes. |
| Owner authorization | The named owner approved the next release level. | Technical verification that was not actually run. |

## Proof language

A workload-admin read verifies embedded artifacts and recorded proof receipts.
It does not start the formal kernels. The truthful fields are:

```json
{
  "embedded_integrity_valid": true,
  "recorded_kernel_receipts_valid": true,
  "formal_kernels_executed_now": false
}
```

`formal_kernels_executed_now=false` is expected for an admin read-back. A fresh
formal-proof claim requires separate exact-head Lean, Coq, and Verus command
evidence.

## Advisory simulation

The browser supplies all seven hypothetical booleans:

1. lease valid;
2. epoch fresh;
3. authorization valid;
4. payload bound;
5. topology complete;
6. workload certificate valid; and
7. workload optimality proven.

The response is a simulation even though it evaluates the real loaded
`VerifiedStickerProgram`:

```json
{
  "evidence_class": "ADVISORY_SIMULATION",
  "authoritative": false,
  "request_bound": false,
  "runtime_effect": "NONE",
  "certificate_issued": false
}
```

Missing, partial, null, or unknown fields must be rejected. Only seven explicit
true values may produce a simulation `PASS`. That result is not an admission
certificate.

## Registry and exact-head interpretation

Always query live metadata before citing a Registry digest or source head:

```text
GET https://lib.trustfortress.ai/api/cubs/meta
GET https://lib.trustfortress.ai/api/cubs/CUB-3211
...
GET https://lib.trustfortress.ai/api/cubs/CUB-3217
```

Equivalent MCP lookup order:

1. `get_registry_meta`;
2. `get_cub` for each exact ID; and
3. `search_cubs` or `list_cubs` only for discovery.

Require a normalized 40-hex source commit before claiming exact-head equality.
An abbreviated Registry head is `INCONCLUSIVE`, even when it is a prefix of the
live GitHub head.

The refreshed public API observation used to prepare this page (Wave 6,
2026-07-31) was timestamped `2026-07-31T01:53:24.932857+00:00` and returned:

- Registry digest
  `c9952e13b9c7aec8325e90f3aaf2be3b213e3f98fc119431a70f33b262bab69e`;
- `cubie-tf` source head
  `d05607bfef93220dd4cfed7499f824d1164cddce`; and
- sampled CUB-3211, CUB-3212, and CUB-3217 from the same digest and update
  marker, each as `VERIFIED`, `invocation=runtime`, and
  `production_consumption=EXECUTABLE-AND-PROOF-ARTIFACT` (the remaining IDs
  CUB-3213..3216 share the same published family declaration; requery each
  exact ID before citing).

That observation is a dated snapshot, not a value to cache. The Registry source
head is a complete commit identifier and matches the workload-admin merge
commit. At the same Wave 6 observation, live GitHub `origin/main` was
`378b8de5528ea1c7199cd0ca7a0ac8e51b1593d8`, so Registry-versus-live-main state
was `DRIFT`, not `PASS`. The publication remains attributable to its exact
source commit. Do not treat the Registry snapshot as "currently live with main"
or merge timestamp-free claims into this page.

Public knowledge-base object prefix for this contract:
`cubie-tf/knowledge-base/2026-07-31/`.

## CUB-3211 through CUB-3217

The public Registry currently describes this family as the workload-bound proof
bundle `workload-bound-proof-family-v1`. The declared proof consumer is
`operator_resource.workload_bound`, and the declared policy effect is
`shadow_advisory_only`.

The declaration is conditional:

- consumption occurs only when OperatorResource receipt assembly executes;
- the runtime and its kill switch can disable that path;
- invalid embedded integrity degrades the proof status rather than silently
  authorizing; and
- the proof kernels do not execute at request time.

Therefore, keep these response fields separate:

- `registry_declared_consumption`;
- `binary_embedded_receipt`; and
- `runtime_observed_consumption`.

Do not relabel a public Registry declaration as a local runtime observation.

## Result states

Use structured states and stable reason codes:

- `PASS`: complete corroboration only;
- `FLUID`: evidence is not bound or not currently observed;
- `INCONCLUSIVE`: a credential, full source head, deadline, or external result
  is unavailable;
- `DRIFT`: independently valid sources disagree on current head or revision;
- `FAIL`: a required check completed and failed; and
- `TAMPER`: digest or identity evidence contradicts a trusted binding.

Network errors, missing GitHub credentials, timeouts, and abbreviated source
heads are never `PASS`.

## Export and credential rules

Without a configured signing authority, the download must say:

```json
{
  "evidence_class": "UNSIGNED_ADVISORY_SNAPSHOT",
  "release_certification": false,
  "canary_authorization": false,
  "enforce_authorization": false
}
```

The gateway application reads only its dedicated workload-admin and GitHub
credentials. Bearer values, GitHub credentials, environment dumps, and raw
principal information must never appear in responses, logs, or downloads.

## Reviewer checklist

Before accepting a workload evidence statement:

1. Record the full source and build SHAs.
2. Requery Registry metadata; do not reuse a prior digest.
3. Verify all seven CUB reads came from one consistent Registry snapshot.
4. Separate declarations, embedded receipts, and runtime observations.
5. Confirm compiler replay used the active verified signed manifest.
6. Label simulation as advisory and non-request-bound.
7. State whether formal kernels executed now.
8. State external certification and owner authorization separately.
9. Confirm `runtime_effect=NONE` for every admin operation.
10. Do not infer Canary or Enforce approval from a diagnostic export.