Receipt Orchestration · Doctrine v6

Operator console for governed AI execution

rosie implements a three-tier khipu pendant-cord receipt DAG with CSS ingress admission control, QEC lineage provenance tracking, and canonical byte-string emission — satisfying Doctrine v6 P6 + P8 dual-attestation requirements.

rosie — CSS-ingress and canonical receipt byte-strings brand graphic

What rosie is

rosie is the operator console and observability node in the SZL Holdings UDS mesh. It processes operator-facing receipt ingress, applies governance lint, and presents cluster health for four mesh components: amaru, rosie, sentra, a11oy.

Receipt Ingest via CSS Ingress

CSS (Calderbank-Shor-Steane) ingress v17 wraps classical payload digests into stabilizer pairs. Each IngressReceipt carries a payloadDigest (UInt8) and a StabilizerPair (x-parity, z-parity). Admission is granted only when cssConsistent(r.stabilizer) holds and stabilizer.xParity === payloadDigest.

Doctrine v6 Ban-Word Sweep

Scans any markdown text against 30+ regex patterns drawn from the Doctrine v6 ban-word list. Returns line and column locations for each violation. Patterns cover filler phrases ("please note", "important note"), superlatives ("world-class", "outstanding"), marketing vocabulary ("synergy", "leverage", "paradigm shift"), and prohibited hedges ("seamlessly", "cutting-edge").

UDS Cluster Health View

Aggregates span data across all four UDS mesh components. Displays total spans, error count, error rate (%), average duration (ms), and spans-per-minute for amaru, rosie, sentra, and a11oy. HUKLLA governance alarm fires when overall error rate exceeds 20%.

The 3 operational modes

Each pane in the operator console targets a distinct governance function. Patterns below are grep-verifiable from szl-holdings/rosie.

Mode A · Receipt-Chain Viewer

Khipu Receipt DAG Browser

Paginated chain browser per mesh component. Each receipt in the three-tier DAG (Decision → Organ → KhipuRoot) is displayed with its SHA-256 hash, chain position, prior-hash linkage, and dual-attestation status. The sum-invariant (verifySumInvariant) and dual-attestation (verifyDualAttestation) are verified on each displayed node.

// Three-tier pendant-cord receipt DAG
buildDecision('d-001', 42, { action: 'approve' })
buildOrgan('organ-alpha', [d1, d2])
buildRoot([organ], ['attester-A', 'attester-B'])

verifySumInvariant(root) // true
verifyDualAttestation(root) // true
Mode B · Doctrine v6 Ban-Word Sweep

30+ Regex Governance Patterns

Real patterns from rosie-operator-console/app.py. The sweep engine uses Python re.finditer across all lines, reporting each hit with line number, column, matched text, pattern source, and 80-character context window.

# Filler phrases
r"\bplease note\b"
r"\bimportant note\b"
r"\bit is worth noting\b"

# Superlatives (banned)
r"\bworld-class\b"
r"\boutstanding\b"
r"\bgroundbreaking\b"

# Marketing vocabulary
r"\bsynergy\b"
r"\beverag(?:e[dsi]?|ing)\b"
r"\bparadigm shift\b"
r"\bgame[-\s]changer\b"

# Prohibited hedges
r"\bseamless(?:ly)?\b"
r"\bcutting[-\s]edge\b"
r"\bstate[-\s]of[-\s]the[-\s]art\b"
Mode C · Gate-Flip Alerts

DSSE Envelope Verifier & HUKLLA Alarms

Validates DSSE (Dead Simple Signing Envelope) PAE v1 payloads from amaru and sentra. The PAE (Pre-Authentication Encoding) constructs: DSSEv1 <len> <payloadType> <len> <payload>. HUKLLA alarms fire when the mesh-wide error rate exceeds 20% or forbidden tokens appear in the receipt chain. Gate-flip events surface in the Span Explorer with component, operation, status, duration, and receipt hash.

# DSSE PAE v1 construction
# from rosie-operator-console/app.py
def _pae(payload_type, payload):
  pt = payload_type.encode()
  return (
    b"DSSEv1 "
    + len(pt) + b" " + pt
    + b" " + len(payload)
    + b" " + payload
  )

Live operator console

The rosie-operator-console Space runs on Hugging Face with Gradio 5. All four panes — Span Explorer, Receipt Verifier, Mesh Health, and Doctrine Sweep — are interactive. The Space is open-source under Apache-2.0.

huggingface.co/spaces/SZLHOLDINGS/rosie-operator-console — Apache-2.0 · Doctrine v6 Open in full tab →

rosie vs SRE / operator dashboards

rosie does not replace general-purpose observability platforms. The comparison below is honest: cells marked ✗ reflect capabilities those tools do not provide, not deficiencies in their design (they are built for different scopes).

Capability Datadog APM Grafana Cloud New Relic Honeycomb rosie
Receipt-chain replay
Lean theorem cross-link per alert ✓ TH11
DSSE envelope view (PAE v1)
Doctrine v6 governance lint ✓ 30+ patterns
Khipu sum-invariant verification ✓ TH11 / Urton
Dual-attestation (P6 + P8) ✓ IETF SCITT
General-purpose metrics ingestion ✗ not in scope
Distributed tracing (OTel) ✗ not in scope
On-call paging / incident mgmt ✗ not in scope
Open source (self-hostable) ✓ OSS core ✓ Apache-2.0
Zenodo DOI / citable artifact ✓ 10.5281/zenodo.20424992

Table reflects capabilities as of June 2026. Datadog, Grafana, New Relic, and Honeycomb are trademarks of their respective owners. rosie does not compete in the SRE platform market.

What rosie is NOT

Honest scope constraints, from the repository's own README and Doctrine v6 requirements. These are design decisions, not limitations.

Not an SRE tool

rosie does not replace Datadog, Grafana, or PagerDuty. It has no general-purpose metrics pipeline, no alert routing, no runbook integration, and no on-call scheduling. If you need SRE observability, use an SRE tool.

Not a metrics aggregator

rosie does not ingest arbitrary metrics, time-series data, or OTel spans from third-party systems. Its span data is UDS-mesh-scoped: amaru, rosie, sentra, a11oy. Integrating external telemetry is out of scope.

Not a paging system

HUKLLA alerts appear in the console UI. rosie does not send SMS, push notifications, or call Slack webhooks. Alert delivery to human operators is handled by whatever incident management layer sits above the UDS mesh.

Not a general document store

Receipts carry structured governance metadata — not arbitrary JSON blobs. The three-tier DAG (Decision → Organ → KhipuRoot) enforces strict typing and sum-invariant constraints. Storing unstructured data violates the schema.

Not production-hardened for adversarial input

CSS ingress v17 does not implement full Byzantine-fault-tolerant admission. The HMAC-SHA-256 key in the operator console Space is a development key (szl-amaru-dev-hmac-key-v1-not-for-production), not a production signing credential.

Not a blockchain ledger

rosie produces canonical byte-strings for on-chain anchoring. Anchoring itself is handled by amaru + Cardano. rosie is not a blockchain node and does not participate in consensus.

Citations

All technical claims in rosie trace to citable primary sources. DOIs are Zenodo-anchored or publisher-issued.

[1]
DSSE PAE v1 — Dead Simple Signing Envelope
Integrity of receipt payloads verified via Pre-Authentication Encoding: DSSEv1 <len> <payloadType> <len> <payload>. Specification: github.com/secure-systems-lab/dsse
[2]
IETF SCITT Architecture (draft-ietf-scitt-architecture-22, 2025)
Dual-attestation pattern in rosie mirrors the SCITT multi-receipt transparent statement. ietf.org/archive/id/draft-ietf-scitt-architecture-22.txt
[3]
OpenTelemetry Specification
Span and trace semantics referenced for UDS mesh span data format. opentelemetry.io/docs/specs/otel/
[4]
rosie — Khipu Receipt DAG with QEC-Governed Ingress (Zenodo DOI: 10.5281/zenodo.20424992)
Lutar, S.P.J.R. (2025). Apache-2.0.
doi.org/10.5281/zenodo.20424992
[5]
SZL Holdings Doctrine v6 (Zenodo DOI: 10.5281/zenodo.19944926)
Governance specification covering ban-word sweep, signed commits (DCO), dual-attestation requirements (P6 + P8), and prohibition on superlatives in technical writing.
doi.org/10.5281/zenodo.19944926
[6]
Calderbank, Shor, Steane — CSS quantum error-correcting codes (1996)
DOI: 10.1103/PhysRevA.54.1098 · Used in rosie's CSS ingress as a classical-to-cosigned receipt bridge. Innovation: the receipt-level instantiation is new — no quantum-AI prior art in 1996.
[7]
Ouroboros Thesis v18 (Zenodo DOI: 10.5281/zenodo.20434276)
Formal basis for the UDS mesh. TH11 (khipuReceipt_checksum_invariant) in lutar-lean formally verifies rosie's sum-invariant via Lean 4.
doi.org/10.5281/zenodo.20434276
[8]
Urton, G. (2003). Signs of the Inka Khipu. University of Texas Press.
DOI: 10.7560/703442 · Khipu summation invariant: primary cord value = Σ pendant values. Medrano & Khosla (2024) confirm the invariant in ≥74% of 650 corpus khipu.