What it may be trusted with. One object, priced by the relying party.
The composition of four profiles for one identity over one window: earned, lineage, behaved, exposed. Each keeps its verdict and status; the credit object adds only binding. The credit-check is the allocate-check with all four behind it. There is no scale, no grade, no letter.
Not a rating, not advice, not a forecast, not a guarantee. Status is the lowest of its parts: DECLARED today.
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.
A PROBATUM credit credential is the composition, for one identity over one window, of:
- earned (profile zero, VTR-1): the record, after costs, every try counted;
- lineage (profile A): the same machine, every retrain a counted version, bound to a model commitment;
- behaved (profile C): the committed policy held over the committed action ledger;
- exposed (profile X): the current risk object under a public rule, positions never shown.
Each part keeps its own verdict, status and clauses. The credit object adds nothing of its own except binding: the four parts are bound to one identity, one window and one log position, and the credit-check reports all four in one signed answer.
- Not a rating. A rating is an opinion on a scale, issued by a party paid by the issuer, that a reader is asked to trust. A credit credential is a set of proven facts a reader re-runs. There is no scale, no grade, no letter. The word "rating" does not appear on a PROBATUM credential.
- Not advice. The credit-check answers "are these four things true of this machine" and never "should you lend". The relying party sets every threshold.
- Not a forecast. Every part attests to a committed history or a timestamped present. Nothing attests to what comes next.
- Not a guarantee. No part of the object is a warranty; reliance is governed by the Terms of Reliance.
The lender, the allocator, the clearer, the insurer. Each applies its own limits to the four parts, in its own policy, in the credit-check call. Two relying parties may reach opposite decisions on the same credential. That is the design: the proof is shared, the judgement is not.
POST /api/credit-check {agent | credential, policy?, policy_id?} is the allocate-check with all four profiles behind it: the same signed ALLOW or REFUSE, the same clause-tagged checks, the same 24-hour token, failing closed. Status of the response is the lowest status among the parts it relied on, printed in the response. At this draft: earned LIVE, lineage DRAFT (check LIVE), behaved DECLARED, exposed DECLARED, so the credit-check is DECLARED.
Every rung below this one answers one question. To our knowledge this is the first object that answers the question a balance sheet asks: what may this machine be trusted with. Credit is where the standard ends up: one object combining what a machine earned, how it behaved and what it is exposed to. The proof-grade loss data it accumulates is, to our knowledge, not assembled anywhere else. The venue and the settlement layers above it are ways of charging for it, by a separate entity. The issuer never earns from the capital that moves on it.
To our knowledge, no issuer composes earned, lineage, conduct and exposure into one re-runnable object for a machine. Tell us what we missed.