Disclosure policy — what leaves the machine, and who chooses

The principle: disclosure is the customer's choice, with a safe default — never a hardcoded "never". What a run reveals to the outside world differs by destination and by customer, so it is a knob, not a constant. But the default is always the safe one, and one boundary is fixed for the customer's own protection.

Litatoli is the only source of authority

None of the exports below is evidence. The sealed Litatoli chain is the single authoritative record; everything here is a projection of it for operations or interoperability. A collector, a SIEM, or a transparency log going down, lying, or being unreachable never authorises a forbidden action and never turns a proof into a non-proof.

Three destinations, three postures

1. The customer's own observability (OTLP / SIEM) — fully configurable

run --otlp projects the run's key events into an OpenTelemetry trace for the customer's own Splunk / Elastic / Datadog / Collector. Because it is their sink, they choose how much detail it carries — --otlp-disclosure:

Level	What it carries
minimal (default)	ids, digests, host-only targets — leaks nothing sensitive
standard	+ full target URLs, decision reasons, exit code
verbose	+ the workload's OWN sealed self-report (stdout/stderr)

Even verbose emits only what the enforcer already sealed into the chain — it never invents a value, and the chain carries events, not request bodies. An unknown level falls back to minimal (fail-safe).

2. A public transparency log (Rekor, RFC 3161 TSA, SCITT) — commitment only, by design

Here the customer does NOT get a "publish content" knob, and that is deliberate, not an oversight:

• A public log is permanent and world-readable; the customer cannot take an entry back. Publishing what ran, or how, there would be irreversible.
• These logs store a digest by their own format — a Rekor hashedrekord is a sha256 — so content cannot leak to them whatever we send. We log head_commitment(head) = sha256:<hex>; a party holding the original chain recomputes it and checks inclusion, a party holding only the log sees an opaque digest.

So the floor here is fixed to protect the customer. It is documented, not silent.

3. A registry the customer controls (customer ledger) — the "publish more" path

When a customer genuinely wants to record more than a commitment in a registry they run themselves, that is the HttpLedgerWitness — their own hash-chained ledger, on infrastructure they control, under their own retention and access rules. That is where "send more" belongs: a sink whose exposure they own, not a public log whose exposure they cannot undo.

The one hard rule

Configurable everywhere it is the customer's own exposure to weigh; a fixed floor only where the exposure is public, permanent, and irreversible. No secret or credential VALUE is ever emitted by any export — the chain does not carry request bodies, and the OTLP projection reads events, never payloads.