JEP Receipt Profile: Verifiable Behavior and Evidence Receipts

3.1. JEP-RP-1 Defines

JEP-RP-1 defines:¶

• one explicit Receipt Profile identifier;¶
• one critical receipt-binding extension;¶
• one minimal behavior-record format;¶
• one receipt-manifest format;¶
• receipt-bundle packaging semantics;¶
• independent receipt-validation checks;¶
• privacy and non-inference requirements.¶

3.2. JEP-RP-1 Does Not Define

JEP-RP-1 does not define:¶

• new JEP verbs;¶
• an independent signature format;¶
• a replacement for Event Identity or Event Hash;¶
• chain causality or complete-log semantics;¶
• authorization or delegation validity;¶
• legal liability, fault, intent, negligence, consent, fairness, or harm;¶
• regulatory compliance;¶
• monitoring duties, sanctions, remedies, or appeal rights;¶
• a global identity or trust framework;¶
• a mandatory archive format;¶
• a global model, tool, risk, or policy taxonomy.¶

3.3. JEP Ownership

JEP-Core is authoritative for:¶

• J, D, T, and V semantics;¶
• required Core event fields;¶
• Event Identity (who,id);¶
• Event Hash;¶
• the JEP Signing Payload;¶
• signature processing;¶
• ref;¶
• ext and ext_crit;¶
• independent Core validation checks;¶
• validation modes;¶
• acceptance outcomes and idempotent acceptance.¶

JEP-RP-1 MUST NOT redefine those semantics.¶

3.4. Actor, Signer, and Observed Agent

JEP-RP-1 distinguishes three concepts:¶

• JEP actor: the actor claimed by the JEP who field;¶
• signer: the key holder that produced the JEP signature;¶
• observed agent: the AI agent, runtime, service, or automated component described by the behavior record.¶

These MAY refer to the same entity, but JEP-RP-1 MUST NOT assume that they do.¶

Actor/key binding is determined by the selected trust profile.¶

The observed-agent identifier is evidence content. It does not establish that the observed agent controlled the signing key or emitted the JEP event.¶

4.1. Receipt Profile Identifier

The JEP-RP-1 profile identifier is:¶

https://humanjudgment.org/jep/profiles/receipt/1/draft-01

The human-readable label JEP-RP-1 identifies the record-format family. The URI above identifies the specific experimental semantic contract first defined in this revision. The suffix draft-01 is a literal part of that identifier, not a negotiation parameter or an instruction to fetch the latest draft.¶

The profile identifier is a publisher-controlled HTTPS URI. Implementations MUST compare it as an exact string. Dereferencing it is not required for validation and MUST NOT select different rules. Documentation at the URI SHOULD remain available; redirects or document updates MUST NOT change the identified semantic contract.¶

4.2. Receipt-Binding Extension Identifier

The JEP-RP-1 receipt-binding extension identifier is:¶

https://humanjudgment.org/jep/extensions/receipt-binding/1

An event claiming JEP-RP-1 conformance MUST carry this extension under JEP ext and MUST list the identifier in ext_crit.¶

A verifier that does not understand this critical extension cannot claim successful JEP-RP-1 validation.¶

Unknown critical-extension handling remains a JEP-Core requirement: an unknown critical receipt extension causes extension_processing to fail. It MUST NOT be downgraded to a successful Core result or merely ignored.¶

4.3. Version and Naming Boundary

JEP-RP-1 is not wire-compatible with the HJS-Core-1 binding model used by draft-wang-hjs-accountability-05.¶

HJS-Core-1 commonly placed an external record digest in JEP what. That model is not a valid generic binding rule for JEP-Core 0.7 because D, T, and V have verb-specific required what members.¶

JEP-RP-1 therefore moves receipt binding into a critical JEP extension and leaves Core what semantics entirely under JEP-Core.¶

Historical HJS-Core-1 receipts MUST NOT be silently rewritten as JEP-RP-1 receipts.¶

The Receipt Profile identifier is distinct from the optional HJS Archive and Privacy Profile family identifier jep-profile:hjs-archive:1 in [JEP-PROFILES]. Neither identifier is an alias for, or implicitly selects, the other.¶

Revision -00 used https://humanjudgment.org/jep/profiles/receipt/1. This revision uses the distinct identifier in Section 4.1 because it adds constraints and resolves previously unspecified behavior. The two identifiers MUST NOT be treated as aliases. The receipt-binding extension identifier remains unchanged; its signed profile member selects the contract. The record-format markers "1" do not independently select a profile.¶

A verifier MUST explicitly select the supported Receipt Profile contract in its validation context and compare it with the signed extension value. The selected identifier determines these rules without a separate agreement on an Internet-Draft revision. An absent selection leaves profile-binding indeterminate; an explicit selection that conflicts with the signed value makes it fail. Independently established failures retain precedence. A verifier MUST NOT try older profiles after failure, infer a version from the first passing rule set, or fetch an identifier and execute newly supplied rules.¶

A handler that recognizes the receipt extension but cannot process its selected profile contract MUST NOT mark critical-extension processing successful. An unsupported profile contract leaves that processing unresolved under JEP-Core; an unknown critical extension itself still fails as required by JEP-Core. When validation explicitly requests this profile, a different signed profile value fails profile-binding. These cases MUST remain distinguishable in the report.¶

Once published, this identifier MUST retain the semantic contract defined here. An editorial revision that preserves that contract MAY keep the identifier. A materially incompatible contract MUST use a new profile identifier, including during experimentation. A later stable specification MUST NOT silently redirect, alias, or reinterpret older identifiers. This follows the versioning model in [JEP-PROFILES].¶

Historical artifacts and reports MUST retain their original bytes, identifiers, and declared rules. Implementations MAY separately support -00. Migrating to this profile requires a new binding event carrying its identifier and a conforming primary record; the old event is not edited or relabeled. A behavior record already meeting these rules may retain its content and digest. A manifest contains the profile identifier, so migration changes its content and digest. An evaluation of old record content against new rules is not proof that the old signed event claimed the new profile. See Table 3.¶

5.1. Receipt Event

A JEP-RP-1 Receipt Event is a JEP-Core event that:¶

• validates under the requested JEP validation mode and selected profiles;¶
• carries the JEP-RP-1 receipt-binding extension;¶
• lists that extension in ext_crit;¶
• binds exactly one primary receipt record by digest.¶

The underlying JEP verb remains authoritative.¶

5.2. Use of J, D, T, and V

JEP-RP-1 does not assign new meanings to J, D, T, or V.¶

A producer MUST satisfy the JEP-Core requirements for the selected verb before receipt binding is considered.¶

In particular:¶

• a D event MUST retain the Core D what.delegatee and what.scope semantics;¶
• a T event MUST retain the Core T what.termination_scope and ref semantics;¶
• a V event MUST retain the Core V what.verification_scope, what.result, and ref semantics.¶

Receipt metadata MUST NOT replace those Core fields.¶

5.3. who

The JEP who field identifies the actor claimed by the Receipt Event.¶

JEP-RP-1 MUST NOT describe who as a verified signer identity unless the applicable actor-binding check actually passed.¶

who SHOULD NOT contain plaintext personal information unless the deployment requires that form and has an appropriate privacy basis.¶

5.4. ref

JEP-RP-1 uses JEP ref exactly as defined by JEP-Core.¶

A logical reference to another JEP event SHOULD use Event Identity. An optional Event Hash MAY pin an exact signed artifact.¶

JEP-RP-1 MUST NOT use Event Hash as a substitute for stable Event Identity when the reference is logically about an event.¶

The presence of a JEP reference does not establish causality, completeness, authorization, endorsement, or legal effect.¶

6.1. Extension Value

The receipt-binding extension value MUST be a JSON object containing:¶

• profile¶
• record_type¶
• record_digest¶
• media_type¶

profile MUST equal https://humanjudgment.org/jep/profiles/receipt/1/draft-01.¶

record_type MUST be one of:¶

• behavior¶
• receipt-manifest¶

record_digest MUST be the sha256: digest string defined in Section 6.4 for the entire primary record. Other algorithms require a separately selected specification and are not baseline JEP-RP-1 conformance.¶

media_type MUST equal the string application/json for either baseline primary record type. The declared record_type MUST agree with the supplied record format; a verifier MUST NOT infer a different type to make a record pass.¶

The extension MAY additionally contain record_uri. If present, record_uri is a retrieval hint only. Validation MUST NOT depend solely on trusting the retrieved location.¶

record_uri, when present, MUST be a non-empty string containing a URI as defined in [RFC3986]. Retrieval is optional and subject to local access policy; the URI is not an integrity substitute.¶

6.2. Extension Example

NOTE: '\' line wrapping per RFC 8792

{
  "ext": {
    "https://humanjudgment.org/jep/extensions/receipt-binding/1": {
      "profile": "https://humanjudgment.org/jep/profiles/receipt/1/\
draft-01",
      "record_type": "behavior",
      "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "media_type": "application/json"
    }
  },
  "ext_crit": [
    "https://humanjudgment.org/jep/extensions/receipt-binding/1"
  ]
}

The example digest is illustrative and is not a test vector.¶

6.3. One Primary Record

Each JEP-RP-1 Receipt Event binds exactly one primary receipt record through the receipt extension.¶

Additional evidence objects are referenced from that primary record or a receipt manifest. This rule avoids ambiguity about which object the Receipt Event primarily authenticates.¶

6.4. JSON Input and Digest Rules

The rules in this section apply to complete behavior-record and receipt-manifest JSON values, including all nested values and any additional members. The JEP event itself remains subject to the JEP-Core input and signing rules.¶

Serialized record input MUST be UTF-8 JSON conforming to [RFC8259], the I-JSON restrictions in [RFC7493], and the input requirements of [RFC8785]. The top-level value MUST be an object. An implementation MUST reject an input that cannot be processed in this domain; it MUST NOT repair an invalid input and then report the original input as valid.¶

Duplicate object member names MUST be rejected at every nesting level during parsing, before constructing a map that could discard duplicates. Name comparison takes place after JSON escape decoding: "a" and "\u0061" are the same name. A parsed-object API MUST require an equivalent guarantee from its input parser; a map alone cannot establish that the original input had no duplicates.¶

Invalid UTF-8, invalid Unicode data such as an unpaired surrogate, Unicode noncharacters prohibited by I-JSON, invalid JSON number syntax, and non-finite numbers MUST be rejected. Numeric values MUST be handled using the IEEE 754 binary64 model required by JCS. Inputs that overflow that finite domain MUST be rejected. Implementations MUST NOT substitute an arbitrary-precision JSON serializer for the JCS number serialization rules.¶

The digest input is the complete top-level record JSON value, not a named subobject and not a serialization containing only recognized members. Every accepted member and value contributes to the digest. Structural validation MUST NOT mutate this value. Implementations MUST NOT remove members, insert defaults, omit explicit null values, change array order, normalize Unicode, coerce strings to numbers, or otherwise transform the value before hashing, except for processing prescribed by RFC 8785.¶

This rule does not preserve JSON whitespace, escape spelling, object member order, or number spelling. JCS specifies their serialization, including UTF-16 code-unit ordering of object names, the serialization of negative zero as 0, and the binary64 handling and serialization of numbers. It preserves array order and performs no Unicode normalization. A need to preserve precision beyond binary64 must be addressed when constructing the record, for example with an application-defined string representation; a verifier MUST NOT silently convert a numeric member to a string.¶

An optional member that is absent is different from a present member with the value null. If the declared type of a member excludes null, its presence with that value is a structure error, not a request to remove the member. Additional members are permitted unless an explicitly selected companion profile restricts them. A baseline verifier MUST retain them for canonicalization, MUST NOT assign them unstated baseline semantics, and MUST NOT claim that companion semantics were checked when they were not.¶

The baseline calculation is:¶

canonical_bytes = UTF8(RFC8785(record))
digest_bytes = SHA-256(canonical_bytes)
digest_text = "sha256:" + lowercase_hex(digest_bytes)

canonical_bytes is exactly the UTF-8 output of JCS, with no byte order mark, trailing newline, length prefix, or additional envelope. An API that already returns the JCS UTF-8 octets MUST NOT UTF-8 encode those octets a second time. The textual representation MUST contain exactly the sha256: prefix followed by 64 lowercase hexadecimal digits. A verifier MUST compare the recomputed digest, not the source JSON text or a retrieval URI.¶

These rules specify an algorithm, not an implementation dependency. A conforming implementation can use any implementation that produces the required bytes and rejects invalid inputs.¶

7.1. Required Shape

A JEP-RP-1 behavior record MUST be a JSON object containing:¶

• jep_receipt_record¶
• record_type¶
• agent¶
• action¶
• created_at¶
• evidence¶

jep_receipt_record MUST equal "1".¶

record_type MUST equal "behavior".¶

agent MUST be a JSON object containing a non-empty string id. agent.role and agent.deployment_id MAY be present as non-empty strings.¶

action MUST be a JSON object containing a non-empty string type. Additional action fields are deployment-defined.¶

created_at MUST be a non-negative integer representing declared Unix seconds for record creation. It is not trusted time or proof of freshness.¶

evidence MUST be a JSON array of zero or more Evidence Descriptors.¶

The record MAY additionally contain:¶

• human_participants¶
• context¶
• redaction¶

No other top-level members are defined by JEP-RP-1. Additional structured content SHOULD be placed in evidence objects or defined by an explicitly selected companion profile.¶

7.2. Evidence Descriptor

An Evidence Descriptor MUST be a JSON object containing:¶

• kind¶
• digest¶

kind MUST be a non-empty string describing the evidence class.¶

digest MUST be an algorithm-tagged digest string.¶

An Evidence Descriptor MAY additionally contain:¶

• media_type¶
• uri¶
• redaction¶

media_type, when present, MUST be a non-empty string.¶

uri, when present, is a retrieval hint. A verifier MUST NOT treat URI dereference success as evidence-integrity success.¶

redaction, when present, SHOULD be one of:¶

• none¶
• partial¶
• digest-only¶
• withheld¶

A companion profile MAY define additional redaction values.¶

Each descriptor is an object. Its digest identifies the exact evidence artifact octets under Section 9.4. For the baseline it MUST use sha256: followed by 64 lowercase hexadecimal digits. uri MUST be a non-empty URI string if present. redaction MUST be a non-empty string if present. Additional redaction labels require an explicitly selected companion profile for their interpretation; a label alone does not verify a redaction operation.¶

7.3. Human Participant Reference

human_participants, when present, MUST be an array of structured references.¶

Each reference MUST contain:¶

• role¶
• reference_type¶

role and reference_type MUST be non-empty strings.¶

If reference_type is not withheld, the object MUST contain reference.¶

If reference_type is withheld, reference MUST be absent.¶

A reference MAY contain privacy_mode and salt_holder.¶

JEP-RP-1 does not guarantee anonymity or unlinkability. Timing, metadata, content similarity, device identifiers, storage locations, or salt reuse can create linkability.¶

Each reference MUST be an object. reference, when required, MUST be a non-empty string. privacy_mode and salt_holder, when present, MUST be non-empty strings. Their presence describes a reference method or salt custodian; it is not evidence that an identity, privacy claim, or salt-management procedure has been verified.¶

7.4. Context and Redaction

context, when present, MUST be a JSON object whose semantics are defined by the deployment or companion profile.¶

redaction, when present, MUST be a JSON object describing minimization or redaction applied to the behavior record or its referenced evidence.¶

The presence of a redaction descriptor does not prove that redaction was legally required, sufficient, complete, or correctly performed.¶

7.5. Behavior Record Digest

The Behavior Record Digest MUST be calculated using the complete behavior-record value and the exact input, canonicalization, SHA-256, and textual-encoding rules in Section 6.4. In particular, evidence, human_participants, context, redaction, and accepted additional fields are included when present.¶

The receipt-binding extension is part of the JEP event, not a wrapper to add to the behavior record. The behavior-record digest MUST NOT be calculated by applying the JEP signing-payload rule that omits sig; there is no such field exclusion for receipt records.¶

A behavior record MUST NOT embed the Event Hash of the JEP event that binds it, because doing so would create a circular artifact dependency.¶

8.1. Manifest Shape

A JEP-RP-1 receipt manifest MUST be a JSON object containing:¶

• jep_receipt_manifest¶
• profile¶
• root_event¶
• events¶
• records¶
• created_at¶

jep_receipt_manifest MUST equal "1".¶

profile MUST equal https://humanjudgment.org/jep/profiles/receipt/1/draft-01.¶

root_event MUST be an Event Descriptor.¶

events MUST be a non-empty array of Event Descriptors.¶

records MUST be a non-empty array of Record Descriptors.¶

created_at MUST be a non-negative integer representing declared Unix seconds for manifest creation. It is not trusted time.¶

A receipt manifest MAY additionally contain:¶

• external_refs¶
• redaction¶

external_refs, when present, MUST be an array of Evidence Descriptors as defined in Section 7.2. redaction, when present, MUST be an object with the limitations in Section 7.4. Additional members follow Section 6.4.¶

8.2. Event Descriptor

An Event Descriptor MUST contain event_identity:¶

{
  "event_identity": {
    "who": "did:example:agent-123",
    "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
  }
}

The Event Descriptor and its event_identity member MUST each be objects. The who and id values MUST satisfy the corresponding JEP-Core field rules, including a non-empty ASCII id. Comparison uses the exact JEP Event Identity values; a verifier MUST NOT normalize, case-fold, or substitute an Event Hash for them.¶

An Event Descriptor MAY additionally contain:¶

• event_hash¶
• uri¶

event_hash, when present, pins one exact signed event artifact.¶

uri, when present, is only a retrieval hint.¶

Every Event Identity in events MUST be unique within the manifest.¶

root_event.event_identity MUST equal one Event Identity listed in events.¶

If root_event.event_hash is present, it MUST equal the Event Hash for the corresponding exact signed artifact, except as prohibited by Section 8.4.¶

event_hash, when present, MUST be a JEP algorithm-tagged Event Hash. Baseline implementations MUST support JEP-Core sha256. uri, when present, MUST be a non-empty URI string. If both the root descriptor and its matching entry in events include an Event Hash, their values MUST agree. A supplied event MUST match its descriptor's Event Identity as well as any Event Hash pin.¶

8.3. Record Descriptor

A Record Descriptor MUST contain:¶

• record_type¶
• digest¶

record_type MUST be a non-empty string.¶

digest MUST be an algorithm-tagged digest string.¶

A Record Descriptor MAY additionally contain:¶

• media_type¶
• uri¶

The digest, not the URI, is the integrity identity of the record.¶

A Record Descriptor MUST be an object. media_type, when present, MUST be a non-empty string, and uri, when present, MUST be a non-empty URI string. For behavior and receipt-manifest, digest MUST be the baseline JCS/SHA-256 digest of that record type, and a present media_type MUST equal application/json. Other record_type values identify opaque artifacts whose baseline digest is defined in Section 9.4; additional structure semantics require a selected companion profile.¶

8.4. Binding-Event Circularity Rule

If a JEP Receipt Event binds a receipt manifest as its primary record, that manifest MUST identify the binding event by Event Identity and MUST NOT include the binding event's Event Hash anywhere in the manifest.¶

This rule applies to both root_event and any corresponding entry in events.¶

The manifest MAY include Event Hash values for other JEP events.¶

A verifier MUST reject a manifest that includes the binding event's Event Hash, because the binding Event Hash depends on the signed extension containing the manifest digest and would create a circular artifact dependency.¶

8.5. Manifest Digest

The Manifest Digest MUST be calculated over the complete receipt-manifest value according to Section 6.4. The root_event, events, records, created_at, and all present optional or additional members are included without field exclusions.¶

A Receipt Event MAY bind a receipt manifest as its primary record by using record_type equal to receipt-manifest in the receipt-binding extension. The circularity constraint in Section 8.4 is checked without deleting any member from the digest input.¶

9.1. Bundle

A JEP receipt bundle is a packaging concept containing zero or more:¶

• signed JEP events;¶
• behavior records;¶
• receipt manifests;¶
• validation reports;¶
• external evidence objects.¶

JEP-RP-1 does not define a validation-report primary record type. Reports MAY appear as bundle artifacts. The portable result object in Section 10.6 describes a verifier observation; it does not make a report a receipt, a signature, or a new primary-record format.¶

JEP-RP-1 does not define a mandatory ZIP, CBOR, JSON, archive, transport, or storage container.¶

Packaging MUST NOT alter signed JEP event bytes or misrepresent digest-bound record content.¶

9.2. Partial and Redacted Export

A bundle MAY contain only a subset of available evidence.¶

A partial or redacted export MUST NOT present omitted material as nonexistent, unchanged, irrelevant, agreed, waived, or verified.¶

Where omission could affect interpretation, the export SHOULD include an explicit withheld, redacted, or partial-view indication.¶

A digest of an original artifact does not verify a different redacted artifact. If only a redacted artifact is supplied, its bytes can be verified only against a digest that commits to those bytes, unless an explicitly selected specification defines and verifies a separate disclosure proof. If the original is required but unavailable, its integrity check is indeterminate; a redaction label cannot make it pass.¶

A producer exporting a modified behavior record or manifest MUST calculate its new digest and, if claiming a receipt binding for that modified record, obtain a new binding event. It MUST NOT reuse the original binding as if the modified value were the original. The original artifact and its historical binding remain unchanged.¶

9.3. No Chain Inference

A bundle containing multiple events is not, merely by being a bundle, a causal chain, responsibility chain, authorization chain, or complete event history.¶

Chain reconstruction, cycle analysis, termination cascade, complete-log assumptions, and causal interpretation belong to a selected chain profile or external system.¶

9.4. External Artifact Digest Input

The digest in an Evidence Descriptor commits to the exact octet sequence of one identified evidence artifact. The digest in a Record Descriptor with a record_type other than the reserved values behavior and receipt-manifest has the same octet-sequence meaning. The baseline is SHA-256 over those octets with the textual representation specified in Section 6.4.¶

These opaque-artifact digests MUST NOT apply JCS, whitespace removal, newline conversion, Unicode normalization, decompression, redaction, or a format conversion as an implicit preprocessing step. A JSON media type does not select JCS. If a producer wants to commit to a transformed representation, that representation is a distinct artifact whose exact bytes are the digest input.¶

The packaging or retrieval mechanism MUST identify the artifact octets supplied to the verifier, separately from transport framing or an archive container. If transfer or content coding is used, the mechanism MUST specify how the identified artifact octets are recovered. In the absence of that agreement a verifier MUST report the affected required integrity check as indeterminate, rather than trying transformations until a digest matches.¶

A descriptor for a JEP-RP-1 behavior record or manifest in the manifest's records array uses its reserved record_type and the JCS record-digest rule. An Evidence Descriptor always uses the opaque-artifact rule, even if its artifact happens to contain a JSON receipt record. A verifier MUST select the rule from the descriptor's defined context, not from filename, URI, or media type.¶

The JEP-RP-1 baseline digest fields in this document use sha256. A different algorithm label in one of those fields violates the selected baseline and MUST fail the applicable descriptor or extension structure check; it is not merely an unsupported implementation feature. A companion specification can define separately identified fields or a different profile contract for additional algorithms, but MUST NOT change the meaning of a baseline field under the same selected rules.¶

10.1. Layer Separation

Receipt validation reports separately:¶

• JEP-Core validation status;¶
• Receipt Profile checks;¶
• Receipt Profile overall status.¶

JEP-RP-1 MUST NOT replace or overwrite the underlying JEP validation result.¶

Receipt binding is processed by the handler for the critical receipt extension during JEP validation. Implementations MAY perform local parsing, structure, and cryptographic checks separately, but MUST NOT finalize an overall JEP success while mandatory critical-extension processing remains unresolved. They MUST preserve the independent Core check results.¶

For a recognized receipt extension, the required primary-record binding and structure checks are part of processing that extension. Failure of those checks makes the extension fail; inability to obtain required input leaves that processing indeterminate. This does not change the Core rule that an unknown critical extension fails. Supplemental bundle checks do not redefine the Core extension result when the primary binding itself has been completely checked.¶

10.2. Baseline Validation Mode

A JEP-RP-1 Verifier MUST support JEP archival validation mode.¶

If no JEP validation mode is explicitly requested, receipt validation MUST use archival mode.¶

Archival receipt validation MUST NOT consume JEP acceptance state.¶

A deployment MAY additionally request acceptance, chain, or policy mode when those semantics are required. Those modes remain JEP modes and MUST NOT be redefined by this profile.¶

A requested but unsupported mode MUST NOT be silently replaced with archival. The default applies only when the request omits a mode. The verifier MUST report the effective mode, including a mode selected by default.¶

10.3. Receipt Profile Checks

The initial JEP-RP-1 check identifiers are:¶

• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#profile-binding¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#receipt-extension¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#record-binding¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#record-structure¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#manifest-structure¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#bundle-integrity¶
• https://humanjudgment.org/jep/profiles/receipt/1/draft-01#privacy-reference-format¶

Check statuses use the JEP conformance vocabulary:¶

• pass¶
• fail¶
• not_checked¶
• not_applicable¶
• unsupported¶
• indeterminate¶

A verifier MUST NOT report an unperformed Receipt Profile check as pass.¶

10.4. Receipt Profile Overall Status

The Receipt Profile overall status is one of:¶

• valid¶
• invalid¶
• indeterminate¶

For the requested Receipt Profile validation context:¶

• invalid means the underlying required JEP validation is invalid or at least one required Receipt Profile check failed;¶
• indeterminate means no required check failed, but the underlying required JEP validation is indeterminate or at least one required Receipt Profile check is unsupported, not checked, or indeterminate;¶
• valid means the underlying required JEP validation is valid and every required Receipt Profile check passed or was not applicable.¶

Failure takes precedence over an unresolved check. A required check can be not_applicable only under a stated applicability rule; a verifier MUST NOT use that status to bypass missing evidence. Missing required input produces indeterminate when no required check has failed. An explicit companion policy MAY reject unavailable evidence, but the policy outcome MUST be identified separately and MUST NOT be described as an observed digest mismatch.¶

10.5. Validation Procedure

A verifier MUST perform the applicable operations below before reporting success. It SHOULD follow the ordering shown, integrated with JEP-Core critical-extension processing:¶

1. Fix the validation context, selected profiles, target event, and required inventory, if any.¶
2. Parse and validate the JEP event and its signature under JEP-Core and the selected signature profile. Preserve each Core check result. Do not finalize critical-extension processing or acceptance while receipt checks required by the extension are pending.¶
3. Check the profile identifier, presence and criticality of the receipt extension, and all required extension member types and values.¶
4. Obtain the primary receipt record from supplied data or an allowed retrieval mechanism. Missing data is not a successful binding.¶
5. Parse that complete record using Section 6.4, without discarding duplicates or changing its value. Validate the structure for the declared record type. Calculate and compare its JCS/SHA-256 digest without excluding members.¶
6. Enforce the relevant circularity rule, and check any human participant reference formats. Record structural and cryptographic outcomes separately when both can be determined.¶
7. If inventory verification is requested, perform all required component checks described in Section 10.3.1 and report which components were missing, failed, or omitted from scope.¶
8. Complete the critical-extension handler, retain the resulting JEP-Core status, and calculate Receipt Profile status with the aggregation rules in Section 10.4. In acceptance mode, follow Core acceptance-state rules only after the checks required by that context have completed successfully.¶
9. Return the context, underlying JEP result, Receipt Profile checks, component results when applicable, and Receipt Profile overall status. Do not represent a partial result as a completed result.¶

A syntax, duplicate-name, or JCS-domain error in a supplied primary record makes record-binding fail because no valid canonical input exists. It also fails the applicable structure check. A well-formed JCS value with an incorrect digest makes record-binding fail even if structure passes. A digest match with an invalid record shape makes the applicable structure check fail even though record-binding passes. Missing primary input leaves both applicable checks indeterminate unless an independent failure is already established.¶

A required external artifact that is unavailable is indeterminate. A supplied artifact that does not match its declared digest is fail. An unsupported required mechanism is unsupported. An optional, applicable check that was not performed is not_checked. These statuses MUST NOT be relabeled pass.¶

A successful Receipt Profile result establishes the cryptographic and structural properties actually checked. It does not prove the external truth or completeness of the recorded behavior, nor interoperability of untested protocol or application semantics.¶

fail describes a violation of the selected rules that the verifier has established. unsupported describes an implementation capability that is required by those rules but is unavailable. For example, a sha512: value in a baseline record_digest makes receipt-extension fail. An allowed, explicitly selected companion check that the verifier does not implement is unsupported. An implementation unable to compute mandatory SHA-256 MUST NOT claim conforming verifier capability or report success; that limitation alone does not prove the artifact invalid. Unknown critical extensions still fail according to JEP-Core.¶

10.6. Portable Validation Result

A conforming Receipt Profile Verifier MUST be able to produce the JSON result object defined here. This is a minimum exchange contract for validation results, not an archive container, network API, new signature format, or replacement for the JEP Conformance result. Field names and value semantics below are normative; member order and JSON whitespace are not.¶

The object MUST contain profile, specification, receipt_status, jep, record, checks, context, warnings, and errors. Additional members MAY be included but MUST NOT redefine these members or widen the stated scope. Duplicate names MUST be rejected. Unknown additional members MUST NOT be used to infer successful checks.¶

The context object MUST contain: profiles, a duplicate-free array of the explicitly selected profile identifiers; requested_mode, the requested JEP mode string or null when omitted; scope, either primary-receipt or inventory; and required_checks, a duplicate-free array of the full Receipt check identifiers required in that context. The effective mode is reported in jep.mode. The six minimum primary checks MUST be included in required_checks; bundle-integrity MUST additionally be included for inventory scope. Removing a required check from the array does not change its normative requirement.¶

Any explicitly selected companion rules, signature class, trust/key source, historical-state assumptions, or policy parameters needed to interpret the result MUST be identified in the report, using additional context members or the underlying JEP result as appropriate. Sensitive evidence can be referenced through immutable identifiers rather than disclosed. If the necessary context cannot be reproduced, a consumer MUST NOT treat equal overall status strings as evidence of equivalent validation. This profile does not define or authenticate trust roots.¶

For primary-receipt scope, context.external_artifact_integrity MUST be not_checked and context.inventory MUST be absent. The bundle-integrity check is not_applicable. This combination explicitly states that descriptor content, but not the referenced external artifacts, was assessed.¶

For inventory scope, context.external_artifact_integrity MUST be see_inventory and context.inventory MUST be an object with selection, complete, components, and omitted. selection is manifest-default for the default finite inventory in Section 10.3.1 or explicit for an explicitly selected set. complete is a boolean stating whether that required set was fully determined, not whether its artifacts were all available or valid. It MUST be false if missing input prevents enumeration of required descriptors. An incomplete required set cannot produce a passing inventory result.¶

Each components entry MUST be an object with kind (event, record, or evidence), descriptor (the corresponding complete descriptor object), and status (the check-status vocabulary in Section 10.3). It MUST preserve the results of the component checks actually performed, using a checks object and, for an event, its underlying JEP result. A wholly unavailable artifact can be represented by indeterminate plus an explanatory diagnostic and an empty checks object. All required descriptors MUST be represented; identical descriptors MAY share one entry, but distinct pins or constraints MUST NOT be discarded.¶

The omitted array MUST list known descriptors excluded by an explicitly narrower scope, each as an object with kind, descriptor, and a non-empty reason string. It is empty when no known descriptors were excluded. A missing artifact that is required belongs in components with an unresolved status, not in omitted. Unreferenced packaged files need not be enumerated and acquire no authenticated status. Reported component outcomes MUST aggregate to bundle-integrity using Section 10.3.1; a required failure takes precedence even when complete is false.¶

A consumer MUST check the report target, profile, effective context, required-check set, and aggregation consistency before relying on its outcome. An incomplete or internally inconsistent report is not a successful result under this exchange contract; that defect alone does not prove the underlying receipt invalid. Reports MUST NOT be compared solely by receipt_status. This result object is an unauthenticated verifier observation unless a separately selected mechanism authenticates it. The Receipt Event signature does not authenticate a later report, and a report never substitutes for validation of the underlying evidence.¶

NOTE: '\' line wrapping per RFC 8792

{
  "profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
  "specification": "draft-wang-jep-receipt-profile-01",
  "receipt_status": "valid",
  "jep": {
    "status": "valid",
    "mode": "archival",
    "profile": "jep-core-0.7",
    "event_identity": {
      "who": "urn:example:receipt-signer",
      "id": "receipt-test-1"
    },
    "event_hash": "sha256:d8522307eec9432c1e6b9ee56c2d6c8ed3bcd8f3d\
3584d87092fd85d946ac429",
    "checks": {
      "syntax": "pass",
      "cryptographic": "pass",
      "event_identity": "pass",
      "reference_integrity": "not_applicable",
      "extension_processing": "pass",
      "actor_binding": "not_applicable",
      "freshness": "not_applicable",
      "audience": "not_applicable",
      "chain_integrity": "not_checked",
      "policy": "not_checked"
    },
    "warnings": [],
    "errors": []
  },
  "record": {
    "record_type": "behavior",
    "record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e72374\
5586aac1caa8004c00e013cd6b",
    "computed_record_digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298\
123e723745586aac1caa8004c00e013cd6b"
  },
  "checks": {
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#prof\
ile-binding": "pass",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#rece\
ipt-extension": "pass",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#reco\
rd-binding": "pass",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#reco\
rd-structure": "pass",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#mani\
fest-structure": "not_applicable",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#priv\
acy-reference-format": "not_applicable",
    "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#bund\
le-integrity": "not_applicable"
  },
  "context": {
    "profiles": [
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01"
    ],
    "requested_mode": null,
    "scope": "primary-receipt",
    "required_checks": [
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#pr\
ofile-binding",
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
ceipt-extension",
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
cord-binding",
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#re\
cord-structure",
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#ma\
nifest-structure",
      "https://humanjudgment.org/jep/profiles/receipt/1/draft-01#pr\
ivacy-reference-format"
    ],
    "signature_class": "JEP-Baseline-Ed25519-JWS-JCS-0.7",
    "key_source": "public deterministic fixture key",
    "key_fingerprint": "sha256:56475aa75463474c0285df5dbf2bcab73da6\
51358839e9b77481b2eab107708c",
    "identity_scope": "identifier syntax; no historical state",
    "external_artifact_integrity": "not_checked"
  },
  "warnings": [],
  "errors": []
}

12.1. JEP-RP-1 Producer

A conforming JEP-RP-1 Producer MUST:¶

• produce a JEP event conforming to the applicable JEP Producer requirements;¶
• preserve the selected JEP verb semantics;¶
• include the receipt-binding extension;¶
• list the extension in ext_crit;¶
• use the JEP-RP-1 profile identifier;¶
• bind exactly one primary receipt record by digest;¶
• produce the bound record according to the applicable Receipt Profile record format;¶
• avoid rewriting Event Identity or Event Hash semantics.¶

A producer MUST apply the complete-input and rejection rules in Section 6.4, and MUST identify external artifact octets according to Section 9.4. No alternative canonicalization algorithm is permitted for baseline records.¶

12.2. JEP-RP-1 Verifier

A conforming JEP-RP-1 Verifier MUST:¶

• perform or consume an actual JEP validation result;¶
• support JEP archival validation mode;¶
• process the critical receipt extension;¶
• support JEP-RP-1 behavior-record and manifest digest calculation;¶
• support the required Receipt Profile checks for its claimed validation context;¶
• preserve independent check statuses;¶
• distinguish Event Identity from Event Hash;¶
• distinguish JEP validity from Receipt Profile validity;¶
• enforce the binding-event circularity rule for bound manifests;¶
• return indeterminate when a required check cannot be completed and no required check has failed.¶

A verifier MUST implement the minimum applicable checks and scope reporting in Section 10.3.1. If a required failure is already established, the overall result remains invalid even when another check cannot be completed. Merely supporting a digest library does not constitute full Receipt Profile verifier conformance.¶

A verifier MUST support the portable result contract in Section 10.6. Inventory verification remains the additional capability in Section 12.3; primary-receipt conformance does not imply retrieval, complete inventories, actor authentication, or acceptance processing.¶

12.3. Receipt Bundle Verifier

An implementation claiming Receipt Bundle Verifier capability MUST additionally:¶

• validate manifest structure when a manifest is present;¶
• verify Event Identity descriptors;¶
• verify every required Event Hash pin;¶
• verify every required record digest and report any required missing artifact;¶
• report missing required bundle components as indeterminate, with any independent companion-policy rejection stated separately;¶
• avoid inferring causal-chain completeness from bundle membership.¶

17.1. Behavior Record

NOTE: '\' line wrapping per RFC 8792

{
  "jep_receipt_record": "1",
  "record_type": "behavior",
  "agent": {
    "id": "did:example:agent-789",
    "role": "planner",
    "deployment_id": "runtime-42"
  },
  "action": {
    "type": "tool_call",
    "name": "calendar.create_event"
  },
  "created_at": 1790424000,
  "evidence": [
    {
      "kind": "tool_request",
      "digest": "sha256:1111111111111111111111111111111111111111111\
111111111111111111111",
      "media_type": "application/json",
      "redaction": "digest-only"
    },
    {
      "kind": "tool_response",
      "digest": "sha256:2222222222222222222222222222222222222222222\
222222222222222222222",
      "media_type": "application/json",
      "redaction": "partial"
    }
  ]
}

17.2. J Event Carrying a Receipt Binding

NOTE: '\' line wrapping per RFC 8792

{
  "jep": "1",
  "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0",
  "verb": "J",
  "who": "did:example:receipt-service",
  "when": 1790424000,
  "what": {
    "claim": "agent-behavior-recorded"
  },
  "ext": {
    "https://humanjudgment.org/jep/extensions/receipt-binding/1": {
      "profile": "https://humanjudgment.org/jep/profiles/receipt/1/\
draft-01",
      "record_type": "behavior",
      "record_digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaaaaaaaaa",
      "media_type": "application/json"
    }
  },
  "ext_crit": [
    "https://humanjudgment.org/jep/extensions/receipt-binding/1"
  ],
  "sig": "..."
}

The J what object remains a JEP-Core judgment claim. The receipt-record binding is carried only in the critical receipt extension.¶

17.3. Receipt Manifest

NOTE: '\' line wrapping per RFC 8792

{
  "jep_receipt_manifest": "1",
  "profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
  "root_event": {
    "event_identity": {
      "who": "did:example:receipt-service",
      "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
    }
  },
  "events": [
    {
      "event_identity": {
        "who": "did:example:receipt-service",
        "id": "urn:uuid:018f4f8d-7c63-7c2e-9b43-4ef657eec1c0"
      }
    }
  ],
  "records": [
    {
      "record_type": "behavior",
      "digest": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\
aaaaaaaaaaaaaaaaaaaaa",
      "media_type": "application/json"
    }
  ],
  "created_at": 1790424010
}

This example is suitable for a manifest that is itself bound by the root Receipt Event; therefore the binding event is identified by Event Identity without its Event Hash, avoiding a circular dependency.¶

B.1. minimal-behavior

Input JSON:¶

{
  "jep_receipt_record": "1",
  "record_type": "behavior",
  "agent": {
    "id": "agent:example"
  },
  "action": {
    "type": "observe"
  },
  "created_at": 0,
  "evidence": []
}

Canonical UTF-8 bytes (139 octets), expressed in hexadecimal:¶

7b22616374696f6e223a7b2274797065223a226f627365727665227d2c226167
656e74223a7b226964223a226167656e743a6578616d706c65227d2c22637265
617465645f6174223a302c2265766964656e6365223a5b5d2c226a65705f7265
63656970745f7265636f7264223a2231222c227265636f72645f74797065223a
226265686176696f72227d

SHA-256, in lowercase hexadecimal:¶

e0d6b6bc6cf76a33e9124a4bd7298123e723745586aac1caa8004c00e013cd6b

B.2. minimal-manifest

Input JSON:¶

NOTE: '\' line wrapping per RFC 8792

{
  "jep_receipt_manifest": "1",
  "profile": "https://humanjudgment.org/jep/profiles/receipt/1/draf\
t-01",
  "root_event": {
    "event_identity": {
      "who": "did:example:receipt-service",
      "id": "receipt-1"
    }
  },
  "events": [
    {
      "event_identity": {
        "who": "did:example:receipt-service",
        "id": "receipt-1"
      }
    }
  ],
  "records": [
    {
      "record_type": "behavior",
      "digest": "sha256:e0d6b6bc6cf76a33e9124a4bd7298123e723745586a\
ac1caa8004c00e013cd6b",
      "media_type": "application/json"
    }
  ],
  "created_at": 0
}

Canonical UTF-8 bytes (439 octets), expressed in hexadecimal:¶

7b22637265617465645f6174223a302c226576656e7473223a5b7b226576656e
745f6964656e74697479223a7b226964223a22726563656970742d31222c2277
686f223a226469643a6578616d706c653a726563656970742d73657276696365
227d7d5d2c226a65705f726563656970745f6d616e6966657374223a2231222c
2270726f66696c65223a2268747470733a2f2f68756d616e6a7564676d656e74
2e6f72672f6a65702f70726f66696c65732f726563656970742f312f64726166
742d3031222c227265636f726473223a5b7b22646967657374223a2273686132
35363a6530643662366263366366373661333365393132346134626437323938
3132336537323337343535383661616331636161383030346330306530313363
643662222c226d656469615f74797065223a226170706c69636174696f6e2f6a
736f6e222c227265636f72645f74797065223a226265686176696f72227d5d2c
22726f6f745f6576656e74223a7b226576656e745f6964656e74697479223a7b
226964223a22726563656970742d31222c2277686f223a226469643a6578616d
706c653a726563656970742d73657276696365227d7d7d

SHA-256, in lowercase hexadecimal:¶

c7a9e369784ffefbe3ea2c51abac214010dbe6c48efb64a92568bd1448368c78

This manifest can be the primary record of an event whose Event Identity is (did:example:receipt-service, receipt-1). It omits that binding event's Event Hash and references the behavior record in Appendix B.1. No event signature or inventory validation result is implied.¶

B.3. unicode-null-array-number-boundaries

Input JSON:¶

{
  "jep_receipt_record": "1",
  "record_type": "behavior",
  "agent": {
    "id": "agent:example"
  },
  "action": {
    "type": "observe"
  },
  "created_at": 0,
  "evidence": [],
  "context": {
    "n": null,
    "array": [
      null,
      {},
      []
    ],
    "numbers": [
      -0.0,
      1e-07,
      1e-06,
      1e+20,
      1e+21
    ],
    "names": {
      "\ue000": "bmp",
      "\ud83d\ude00": "non-bmp"
    },
    "strings": [
      "\u00e9",
      "e\u0301"
    ]
  }
}

Canonical UTF-8 bytes (299 octets), expressed in hexadecimal:¶

7b22616374696f6e223a7b2274797065223a226f627365727665227d2c226167
656e74223a7b226964223a226167656e743a6578616d706c65227d2c22636f6e
74657874223a7b226172726179223a5b6e756c6c2c7b7d2c5b5d5d2c226e223a
6e756c6c2c226e616d6573223a7b22f09f9880223a226e6f6e2d626d70222c22
ee8080223a22626d70227d2c226e756d62657273223a5b302c31652d372c302e
3030303030312c3130303030303030303030303030303030303030302c31652b
32315d2c22737472696e6773223a5b22c3a9222c2265cc81225d7d2c22637265
617465645f6174223a302c2265766964656e6365223a5b5d2c226a65705f7265
63656970745f7265636f7264223a2231222c227265636f72645f74797065223a
226265686176696f72227d

SHA-256, in lowercase hexadecimal:¶

41bfc5f24cfea4da326b1a5e37778db049f9d1cc41db1c07d46e4f261fb06259

This input exercises explicit nulls, nested arrays, UTF-16 member-name ordering, canonically distinct Unicode strings, negative zero, and exponent-format boundaries. Removing a null or additional member, reordering an array, or normalizing the two strings before JCS would change the record value and violate the digest-input rules.¶

B.4. Rejection and Status Cases

The following raw JSON snippets are invalid input for canonicalization. They are parser tests, not complete behavior records. A test harness MUST preserve the raw JSON text so that duplicate names are not removed before testing. Each snippet MUST be rejected:¶

{"a":1,"a":2}

{"outer":{"a":1,"\u0061":2}}

{"s":"\ud800"}

{"n":NaN}

{"n":1e400}

A serialized record containing invalid UTF-8 octets is likewise rejected. A parser must not replace the invalid octets with replacement characters.¶

The following cases apply to the complete records above. Other required checks are assumed to pass unless stated otherwise; the examples specify Receipt Profile check results, not signature test vectors.¶

Implementers SHOULD additionally test invalid field types, inconsistent record-type declarations, absent critical markers, Event Identity and Event Hash mismatches, circular manifest bindings, unknown critical extensions, unperformed checks, and historical revision selection. Digest agreement alone does not test these properties.¶