How it behaved. Inside the policy, for the full history, on any venue.
A record proves what was earned; it does not prove the earning stayed inside the rules. This profile commits the policy, commits every action to a ledger, binds the action count inside the proof, and re-evaluates every predicate over the full history. Monitors watch one venue after the fact; this is a proof a stranger re-runs.
The conduct-check runs at the DECLARED class today. Proof-of-Control, Proof-of-Behavior and runtime guards are partners for the rail, cited, not endorsed.
Licence: PROBATUM Open Reliance Licence v0.1 (draft): read, cite, verify and implement freely; never fork; never issue under the name without conformance. Profile zero (VTR-1) stays CC BY 4.0. Read the licence. Nothing on this page is in-circuit unless its chip says LIVE.
"Machine M, bound to identity I, acted under committed policy P over the committed action ledger L, and every action in L satisfied P; the number of actions is the leaf count of L, bound inside the proof." The policy is public to the relying party; the actions, the positions and the method are not.
A record proves what was earned. It does not prove the earning stayed inside the rules: leverage caps, drawdown limits, allowed venues and assets, spend limits, counterparties, forbidden actions, human-override requirements. Monitoring tools watch for breaches and report them after the fact, on one venue, from the operator's own logs. This profile turns the same question into a proof over the full history, on any venue, that a stranger can re-run.
- C-01 Policy P: a committed, machine-checkable rulebook. At minimum a set of predicates over actions and over running state (e.g. gross leverage ≤ k, peak-to-trough drawdown ≤ d, venue ∈ V, asset ∈ A, notional per action ≤ s, counterparty ∉ blocklist, action class ∉ forbidden, human sign-off required for class H). P is committed by hash before the first action it governs.
- C-02 Action ledger L: an append-only Merkle ledger of every action the machine took under P: orders, fills, transfers, calls, messages that move value or change exposure. Each leaf carries a timestamp, a venue, an action class and the fields P needs. L may be venue-pulled or venue-signed (fill provenance grades from the rail) or agent-supplied, and the credential says which.
- C-03 Running state: the derived quantities P refers to (exposure, drawdown, spend to date), recomputed from L inside the proof.
- C-04 Breach: any leaf or state for which a predicate of P is false. A breach is a fact, not a verdict; the credential reports breach count, first breach, and whether P defines a cure.
- C-05 P MUST be committed (hash in the transparency log or counter-signed by the relying party) before the first action it governs. A change of P creates a new policy epoch; epochs are counted.
- C-06 L MUST be committed as it grows: either per-action forward commitments (rail forward ledger) or per-period heads anchored in time. Actions committed after the fact are marked as such and cap the class (§06).
- C-07 The relying party's own policy (the venue policy of the allocate-check) MAY be stricter than P; the conduct-check evaluates both and reports each.
- C-08 Off-ledger actions are out of scope. The credential MUST say "actions not in L are not covered", and a venue-signed ledger is the only grade that bounds omission.
- C-09 The circuit recomputes running state from L and evaluates every predicate of P on every leaf; the outputs are: leaf count N_actions, breach count, first-breach index, epoch count, and the policy hash.
- C-10 N_actions is bound in-circuit as the leaf count of L (the same construction as the trial ledger in VTR-1 R-06/R-24/R-38); a truncated ledger changes the root and is refused.
- C-11 Where P needs prices (drawdown, notional), the price series is committed by hash as in VTR-1 R-10, and its provenance grade is reported.
- C-12 Nothing about the method, the strategy, the model or the content of messages leaves the proof; only P, the counts and the verdict do.
- C-13 A conduct credential MAY be bound to a trading credential of the same identity over the same window; when it is, the pair is reported together and the relying party sees earned and behaved side by side.
- C-14 One call:
POST /api/conduct-check {agent | credential, policy?, policy_id?}. Returns ALLOW or REFUSE, signed, with every check and its clause, valid 24 hours, failing closed. Same token family as the allocate-check (typ=probatum-conduct-check/1). - C-15 Checks, in order: identity resolved (A-26) · policy committed before first action (C-05) · ledger committed and class (C-06, C-08) · breach count and first breach (C-09) · epoch count (C-05) · relying-party policy (C-07) · log inclusion · record age.
- C-16 At the DECLARED class the check reads declared conduct fields and declared breach counts bound to the identity in the registry; it says so in every response ("declared by the agent; not recomputed in-circuit").
- C-17 A refused conduct-check is published beside passes. A decision is about the record, never advice.
- C1 declared: P and breach counts declared by the operator, timestamped, bound to an identity. What the rail provides today.
- C2 counted: L committed forward; N_actions bound; breaches declared.
- C3 proven: C2 and every predicate of P re-evaluated in-circuit over L.
- C4 venue-signed proven: C3 over a venue-signed ledger, which alone bounds omission.
Proof-of-Control (Advanced AI Society, draft) and Proof-of-Behavior (IETF draft) specify evidence that an agent stayed within its controls, graded by how much the producer must be trusted; runtime guards enforce policy before an action executes. This profile is compatible with them and is designed to consume their evidence as L where it is signed. They are partners for the rail, not alternatives to the proof. Cited, not endorsed; no relationship is implied.
Not a monitor, not a guard, not a guarantee of future behaviour. A conduct credential attests that a committed history satisfied a committed policy; it says nothing about the next action.