Cedulon Decision Profile: Reconciling an Agent's Decisions Against Its Effects

4.1. Claim labels

The labels lie in the Private Use range of the CWT Claims registry [RFC8392], below the block the core document uses for the Decision Token (-70301 to -70305) and the countersignature (-70401, -70402), so that no two Cedulon claim maps share a label. Every claim annotated hash carries a SHA-256 [RFC6234] digest rendered as exactly 64 lowercase hexadecimal characters, the grammar of Section 6.1 of [CEDULON], and a value outside that grammar is refused by name at signing and at verification.¶

All thirteen labels are always present; a nullable claim carries CBOR null when it has no value. The thirteenth label is new in this revision; a record with twelve is refused at verification as a claim set that does not have this shape, and the companion carries no records signed under the earlier set outside its own fixtures.¶

decider and subject are opaque identifiers chosen by the deployment. requestHash is the SHA-256 of the request the Decider evaluated, in the canonical encoding of Section 7 of [CEDULON] when the request is a JSON document and over its UTF-8 octets when it is text; this document does not fix the request's fields, and a deployment MUST state what it hashes. policyHash is the SHA-256 of the canonical policy document the Decider applied. inputsHash, when not null, is the SHA-256 of whatever further context the Decider consulted, encoded the same way, so that a later reader can tell two decisions on the same request apart by what else was on the table. reasonCode is a short token the deployment defines; it is carried, not interpreted.¶

ref is the reference under which the allowed effect will appear on the channel, and the key on which the reconciliation matches. effectHash is the SHA-256 of the content of the effect the Decider allowed, over the octets the channel will carry: for a text reply, the UTF-8 octets of the text. The Effect Extract computes the same digest over the same octets (Section 5), so equality of the two is equality of content.¶

effectClass is the class of the effect the Decider allowed, a short name in the vocabulary the channel defines, such as a reply or a post. An Effect Extract row carries the same claim in the same vocabulary (Section 5.1), so equality of the two is equality of class. The class is under the Decider's signature so that what the Decider allowed cannot be read as one class by one reader and another by the next without changing what was signed; the earlier revision carried it on the row only and named the gap.¶

timestampMs is the decision time in POSIX milliseconds. nonce identifies the record. prevRecordHash links records into the Decider's chain: it is the SHA-256 of the previous record's COSE_Sign1 octets, the same input the core's receiptHash takes on the COSE path (Section 7.1 of [CEDULON]), or null for the first record of a chain.¶

4.2. Claim rules

A signer MUST refuse to sign, and a verifier MUST reject, a claim set that breaks any of the following, naming the rule in the refusal (MUST-DP-2):¶

• decision is one of allow, deny, defer.¶

• Every hash-annotated claim that is not null matches the hash grammar.¶

• timestampMs is a non-negative integer of magnitude at most 2^53 - 1, the uint the label table states; a CBOR decoder hands back any number, and the rule is what makes the table true.¶

• An allow carries a non-empty ref and a non-null effectHash. An allow that names no effect is a decision the reconciliation cannot close, and an allow that names no reference is one it cannot find.¶

• An allow carries a non-empty effectClass. An allow that names no class is one whose effect could be matched by a row of any class under the same reference and content, which is the substitution Section 8 names.¶

• A refusal MAY carry an effectClass: it names the class of what was refused, and it is carried, not measured. A refusal binds to the absence of a row of any class.¶

• A refusal carries effectHash null. A refusal binds to the absence of an effect, never to a content hash, so a hash on a refusal would be a claim the audit cannot measure and a second reading of whether the effect occurred. A refusal MAY carry a ref: it names what was refused, and an effect appearing under that reference is the worst finding this profile has (Section 6.3).¶

The verifier MUST apply these rules itself, on the claim map it decoded from the signed payload, and MUST NOT rely on the signer having applied them (MUST-DP-3). The Decider is the party under audit. A Decider that signed a well-formed COSE_Sign1 over a claim map that skips a rule has produced an object whose signature verifies, and a verifier that checked only the signature and the equality of the decoded map with the presented claims would attest it. The companion implementation did exactly that until it was measured: an allow with no reference, signed below the signer's own rules under the pinned decider key, verified true, was attested, was counted as unmatched, and the audit still said the books balanced. The rules now run at both ends.¶

4.3. Presentation and confusion

A Decision Record is presented as Section 6.3 of [CEDULON] states for the core's COSE objects: the signed octets, the decoded claim set, and the Decider's public key as a SubjectPublicKeyInfo PEM beside them. The carried key is not an identity source. Under a pinned decider key a record that verifies under the pin while carrying another key is reported as carried-key-mismatch, a warning, and stays attested; with no pin held the signature check that runs against the carried key says the record is internally consistent and nothing about who signed it.¶

A Decision Record is not a Decision Token. The core's Decision Token (Section 8 of [CEDULON]) is the portable encoding of a PDP allow, carried by the party that will spend; a Decision Record is the Decider's own log of what it decided, kept for audit, and it exists for refusals as well. The two carry different content types and different claim maps. A verifier MUST reject a Decision Record whose content type is not application/cedulon-decision-record+cbor, and MUST reject a token presented as a record or a record presented as a token, on the content type, before the signature is checked and before any claim is read (MUST-DP-4).¶

4.4. The Decider's chain and checkpoints

Decision Records chain on prevRecordHash the way Spend Receipts chain on prevReceiptHash, and the Decider signs epoch checkpoints over them with the checkpoint claim set of Section 11.1 of [CEDULON] unchanged: receiptCount is the number of records in the window, chainHeadHash is the SHA-256 of the last record's COSE_Sign1 octets, and totals is a map from the three decision kinds to decimal counts, {"allow": n, "deny": n, "defer": n}, each rendered as a text string as the core renders its currency totals. A verifier compares the totals it computes over the attested records in the window against the signed map, and a difference is checkpoint-total-mismatch as in the core.¶

Two records that claim the same position in a chain cannot both link to it: the second record's prevRecordHash must be the first's hash, so a Decider that signs two decisions under one nonce, or presents one record twice to the same reader, breaks its own chain and the walk names the break. A verifier MUST walk the chain over every presented record that carries the pinned decider key, not only over the records that verified, so that a record that claims the pin and fails the rules is named by the walk rather than dropped from the population without a word (MUST-DP-5).¶

What the walk establishes is bounded by what one reader holds. A Decider can sign two successors to the same predecessor and show one branch to one reader and the other branch to another; each reader walks a linear chain that verifies, and neither walk names a break. The earlier revision called the chain the equivocation control of this profile, which overstated it and contradicted the core: Section 11 of [CEDULON] states that the presented chain alone cannot satisfy the equivocation requirement, because its epochs are consecutive by construction, and that the comparison which reaches a fork is between the presented checkpoints and the copies a witness recorded (MUST-T11-3). That rule applies to this profile unchanged. The Decider's epoch checkpoints are the Signed Statements the witness records, the verifier compares the witness's copies against the presented chain, and two verified checkpoints for one epoch with different hashes are equivocation. Where no witness was consulted, the chain controls equivocation within the population one reader holds and nothing beyond it, and a report MUST NOT present the chain as settling more than that (the core's MUST-T11-9, with the nouns renamed).¶

5.1. Body and row schema

The extract body is one JSON document with exactly this shape:¶

Each effect row is a JSON object with exactly these members:¶

These member names are normative. The body and its rows follow the core's rail extract (Section 9 of [CEDULON]) in every rule that document states for a JSON body: the text is read for a repeated member name before it is parsed and refused as json-duplicate-key; integers are safe integers; the window is half-open and MUST end after it starts; a missing member, a wrong type, an empty identifier, or a hash outside the grammar is refused by name at both ends, by the signer before it signs and by the verifier before it checks a signature.¶

The profile departs from the rail extract at two points, and a reader who knows the core should note both (MUST-DP-6):¶

• A member this document does not name is refused, on the body and on a row. The core lets a rail add members of its own because a rail is a system the profile does not control; an Effect Extract is produced by a process the deployment does control (Section 7), and the companion measured what a free member can do to a population (Section 3). A later revision may open this once a channel that needs its own members is measured.¶

• A row whose timestampMs falls outside [windowStartMs, windowEndMs) makes the whole extract malformed, refused as effect-outside-window before any signature is checked. The core accepts such a rail extract and names the row (extract-scope-mismatch). Here the extract is the deployment's own document and a window it did not keep is a document it did not produce correctly: a signer applying this schema never produces such an extract, and a verifier refuses one that is presented as a document, whatever else it may also name about its rows. The trade is stated so it can be reversed: a single row out of place fails the whole window closed.¶

effectHash on a row is computed by the extract's signer over the same octets a Decider hashes for its effectHash claim: the content as the channel carried it. A deployment MUST state those octets once for both sides; the companion's example channel hashes the UTF-8 octets of the message text.¶

5.2. Authentication and scope

The extract is signed the way a rail extract is signed: Ed25519 [RFC8032] over the UTF-8 octets of the [RFC8785] encoding of the body, with the signature as base64 and the signer's public key as a SubjectPublicKeyInfo PEM beside the body, neither inside the signed octets. It is a JSON document with a detached signature, not a COSE object, and like the rail extract it has no media type. The earlier revision gave as the reason that the core registers names only for objects whose content type is checked inside a protected header; that test decides what a name must be bound to, not whether a representation needs one, and it is withdrawn as the reason. The reason is Section 3: which population a presented document belongs to is the verifier's call, made by the profile it applies and by the decider, channel, and window it declares (MUST-DP-1, MUST-DP-7), and never the document's. That declaration is the typed outer context a media type would otherwise supply. A name on the extract would be a self-description the verifier is told not to select on, and this document does not register one that its own rule forbids relying on. The day an extract is itself wrapped as a Signed Statement and needs a content type in a protected header, an application/cedulon-effect-extract+json registration is the name to make, without changing the verifier's rule; the extract is not recorded with a witness today. Section 9.3 of [CEDULON] applies unchanged: a signature proves internal consistency and not origin; the verifier MUST hold the extract signer's key out of band and MUST compare keys as SubjectPublicKeyInfo DER; with no key held the guarantee is conditional and unauthenticated-extract is reported; with a key held, an extract that does not verify under it is extract-key-mismatch and its rows are not reconciled (settlement-comparison-skipped, the core's name for the same condition).¶

The extract is scoped to one Decider, one channel, and one window, and Section 9.4 of [CEDULON] applies with the nouns renamed: a verifier that knows which Decider, channel, and window it audits MUST check the extract against them and MUST fail closed on a mismatch (extract-scope-mismatch); one that has not stated the window MUST report unstated-audit-window, one that has not stated the Decider or the channel MUST report unstated-audit-scope, and in either case the guarantee is conditional. The strongest line this profile can print, a balanced audit under an unconditional guarantee, is true of one Decider, on one channel, over one window, and a report that carries it MUST also carry those three (MUST-DP-7).¶

6.1. What binds

A Decision Record expects a row when its decision is allow, and expects none when it is a refusal. For a ref that appears once on each side:¶

• an allow and a row bind when the row's effectHash equals the record's effectHash and the row's effectClass equals the record's effectClass; a difference in the hash is effect-mismatch (the content that occurred is not the content that was allowed), and a difference in the class with the hash equal is effect-class-mismatch (the content that was allowed occurred as something else). The hash is compared first; a row that differs in both is reported for its content;¶

• an allow with no row is decision-without-effect;¶

• a row with no record is effect-without-decision;¶

• a row whose ref a refusal names is effect-against-refusal.¶

The last is the finding this profile exists for. A spend audit has no row that should not be there in the same sense: an aborted receipt that still carries its reference and a settlement under that reference is reported by the core as a settlement without a receipt, and it never told the two cases apart. Here a refusal that was followed by the effect it refused is a different fact from an effect nobody decided on, and it has its own name.¶

A ref that appears more than once on a side is duplicate-ref as in the core, and the repeating reference is then reconciled by count rather than by amount: there is nothing to sum. More rows than records under one reference is effect-without-decision; more records than rows is decision-without-effect.¶

There is no amount, no currency, no manifest, no terms, and no counterparty axis on this profile. The core's counterparty-unbound scope record is not emitted: effectHash binds the content of the effect itself, which is more than a payee name ever bound on spend, and actor on a row is carried for the reader, not measured. The core's boundary rule applies unchanged: an unmatched item inside the declared clock-skew allowance of a window edge is boundary-deferred, and a closing-edge allow whose ref the following extract names is carried, not a finding.¶

6.2. Conservation

With |R| the in-scope Decision Records and |E| the effect rows, the identities the core report publishes hold with the words changed:¶

|R|      = refusals + allows
refusals = deny + defer
allows   = matched + deferred + carried
           + unmatched + repeated + unreconciled
|E|      = matched + deferred
           + unmatched + repeated + unreconciled
matched on |R| equals matched on |E|

A report under this profile MUST publish these counts and MUST name the population they were computed over (MUST-DP-8), for the reason the core gives: a report whose counts do not close is a report that lost a record somewhere, and a reader is entitled to see that without re-running the audit. The report publishes refusals as one count, the core's aborted; the split of that count into deny and defer is the checkpoint's totals (Section 4.4), not a counter of the report.¶

6.3. Finding codes

The identifiers below are for diagnostic output and are not an interoperability surface, as Section 11.5 of [CEDULON] states for the core's codes. Five are new to this profile:¶

The remaining codes a report under this profile can carry are the core's, with the same effect on the verdict and the guarantee: duplicate-ref, boundary-deferred, receipt-chain-break for a break in the Decider's chain (signature, rule, or link), checkpoint-total-mismatch, checkpoint-head-mismatch, window-coverage, equivocation, unauthenticated-extract, extract-key-mismatch, extract-scope-mismatch, extract-settlement-mismatch (a caller-supplied row list that disagrees with the extract), settlement-comparison-skipped, trust-key-unreadable, unauthenticated-issuer, issuer-key-mismatch, carried-key-mismatch, unstated-audit-window, unstated-audit-scope, the witness codes, and malformed-policy-hash; the other hash claims of a Decision Record are refused at verification (Section 4.2) and reach the chain walk rather than a malformed-hash code. Two code names carry a spend noun onto this profile (receipt-chain-break, settlement-comparison-skipped); they are kept so that one catalogue serves both populations, and a later revision may add decision-side aliases. The codes the core defines for a Trade Manifest, a payee countersignature, a beneficiary, or a counterparty are not reachable on this profile.¶

The sentences a report prints beside those codes are another matter. An operator reading a decision report SHOULD NOT have to translate "settlement" as "effect" or "receipt" as "decision record"; an implementation SHOULD print the sentence in the population's own words, and the companion holds that under a test that runs every conformance case and refuses a spend noun in any decision sentence. Counter names in a returned structure are diagnostic and MAY keep the core's names.¶

8.1. D1: An effect occurs against a refusal

The agent, or something acting through its channel access, does what the Decider refused. This is the threat the profile exists for. A Decision Record for the refusal, with the reference it refused, and an authenticated extract that carries an effect under that reference make the event effect-against-refusal, and the audit fails. A refusal that carried no reference cannot support this finding; the effect is then effect-without-decision, which also fails the audit but does not say it was refused. A Decider SHOULD carry the reference on a refusal whenever the channel assigns one before the decision.¶

8.2. D2: Effects without decisions

Something acts on the channel that never asked. Every such effect is effect-without-decision. The control is the extract's completeness, which is the extract root's independence (Section 7); a capture process the Decider controls can leave the effect out.¶

8.3. D3: Substitution of content

The Decider allows one content and the channel carries another. The allow's effectHash and the row's effectHash are computed over the same octets, and a difference is effect-mismatch. The control fails open if the two sides hash different octets, which is why a deployment MUST state the octets once for both (Section 5.1).¶

8.4. D4: The Decider signs below its own rules

A Decider produces a well-formed signature over a claim map that breaks a rule this profile states: an allow with no reference or no content hash, a refusal with a content hash, a hash outside the grammar. Every such record is a record the reconciliation cannot close or would close wrongly. The verifier applies the rules on the decoded payload (MUST-DP-3) and walks the chain over every record that claims the pin (MUST-DP-5), so the record is refused and named rather than attested or dropped.¶

8.5. D5: Equivocation on the record chain

The Decider signs two decisions for one request, or two successors to one predecessor, and offers each to a different reader. Within one reader's population the chain (MUST-DP-5) makes the second record unlinkable: it names the same predecessor as the first, or none, and the walk reports the break. Across readers the chain sees nothing: each holds a linear chain that verifies. The control for that case is the core's witness (Section 4.4): the Decider's epoch checkpoints are recorded with a witness the verifier has pinned, a Transparency Service [RFC9943] being one, and the copies the witness holds are compared against the presented chain. A verifier that consulted no witness has not measured cross-reader equivocation. The guarantee its report prints is the core's, which is defined over the extract, the pins, and the window and does not cover suppression or equivocation beyond the presented chain when no witness was consulted (Section 11 of [CEDULON], MUST-T11-9); measured on the companion, such a report prints unconditional with no warning and no finding, and is silent about the witness it was not given. The silence is this revision's known gap: the claim is narrowed here, in the text, and a report line that names an unconsulted witness is a change to the reconciler both populations share, not made in this revision. A deployment that needs the property records its checkpoints with a witness and gives its readers the witness key.¶

8.6. D6: The class of the effect is substituted

A row of a different class under the same reference and the same content hash: the same text allowed as a reply and carried as a post. The earlier revision named this as a gap, because the record carried no claim for the class and a row of any class matched. The record now carries effectClass under the Decider's signature (Section 4.1), an allow without one is refused (Section 4.2), and a row whose class differs from the allow's with the content hash equal is effect-class-mismatch (Section 6.1). What remains open is the vocabulary: the class names are the channel's, this document does not fix them, and a deployment SHOULD state them beside its statement of what it hashes so that two readers compare the same words.¶

8.7. D7: Silent defaults in capture

The process that turns a channel's log into Decision Records or Effect Extract rows fills a missing value with a default, and the default hashes to something. An allow with no stated content that is hashed as the empty string produces a record that will match an empty effect and mismatch every real one, with no finding that says the content was never stated. Such a process MUST refuse the line by name rather than fill it (MUST-DP-10). The companion's example adapter did fill it until it was measured, and refuses it now.¶

8.8. D8: The capture process is the Decider

The party that produces the Effect Extract is, or answers to, the party that signed the Decision Records. Every finding in D1 and D2 can then be made to disappear by omission, and no signature check detects it. This is the independence statement of Section 7 (MUST-DP-9), and it is a deployment fact the profile can name but not prove. A verifier that holds both roots and cannot state their independence has a conditional result, and MUST say so.¶

10.1. application/cedulon-decision-record+cbor

Type name:

application¶

Subtype name:

cedulon-decision-record+cbor¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary. A COSE_Sign1 structure [RFC9052] in deterministic CBOR [RFC8949], untagged, as profiled in Section 4 and in Section 6 of [CEDULON].¶

Security considerations:

See Section 8 of this document. The object is signed by the party under audit; its evidentiary weight depends on the verifier holding the decider key out of band (Section 7) and on the verifier applying the claim rules of Section 4.2 itself, never on a key the object carries or on the signer's word that the rules were applied.¶

Interoperability considerations:

The claim set is a CBOR map with the labels and types stated in Section 4.1, encoded per [RFC8949] Section 4.2.1. A decoder refuses a duplicate key, an input beyond its stated bounds, and a non-empty unprotected header by name rather than accepting it, as Section 6 of [CEDULON] requires of every Cedulon object. A Decision Record and a Decision Token are distinct objects with distinct content types and are never accepted for one another.¶

Published specification:

This document, Section 4.¶

Applications that use this media type:

Policy decision points and other deciders that log the decisions they take about an agent's actions, and auditors that reconcile those logs against the channels the actions occurred on.¶

Fragment identifier considerations:

N/A¶

Additional information:

Deprecated alias names for this type: N/A. Magic number(s): N/A. File extension(s): N/A. Macintosh file type code(s): N/A.¶

Person and email address to contact for further information:

Emek Can Dogru, e.dogru@cedulon.com¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Emek Can Dogru¶

Change controller:

IETF¶

12.1. Normative References

[CEDULON]

Dogru, E. C., "Cedulon: An Audit Layer for Agent-to-Agent Commerce", Work in Progress, Internet-Draft, draft-dogru-cedulon-08, 2 September 2026, <https://datatracker.ietf.org/doc/html/draft-dogru-cedulon-08>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, October 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

12.2. Informative References

[ABAK]

Abak, A. T., "Evidence Requirements for Agent Control Delivery and Outcome Reconciliation", Work in Progress, Internet-Draft, draft-abak-agent-control-delivery-evidence-01, 4 September 2026, <https://datatracker.ietf.org/doc/html/draft-abak-agent-control-delivery-evidence-01>.

[AEB]

Schrock, I., "The Action Evidence Boundary for Consequential Agent Effects", Work in Progress, Internet-Draft, draft-schrock-action-evidence-boundary-05, 31 August 2026, <https://datatracker.ietf.org/doc/html/draft-schrock-action-evidence-boundary-05>.

[OUTCOME]

Schrock, I., "Outcome Binding for Authorized Actions and Independently Observed Effects", Work in Progress, Internet-Draft, draft-schrock-ep-outcome-binding-00, 28 July 2026, <https://datatracker.ietf.org/doc/html/draft-schrock-ep-outcome-binding-00>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.