signal@humanjudgment.org https://github.com/hjs-spec

JEP conformance interoperability test vectors judgment events This document defines conformance classes, validation-result structure, schema requirements, test-vector categories, conformance assertions, reference-validator behavior, implementation disclosure, and interoperability testing guidance for the Judgment Event Protocol (JEP). It is a companion to JEP-Core 0.7. This document does not redefine JEP-Core semantics. Its purpose is to make JEP-Core 0.7 implementations testable and interoperable across languages, platforms, trust profiles, and deployment environments. Conformance artifacts described by this document are derived from applicable normative specifications; tests, schemas, examples, and reference implementations do not independently create JEP-Core semantics.

Introduction JEP-Core defines the signed event object, J/D/T/V event semantics, stable Event Identity, Event Hash semantics, validation modes, independent validation checks, extension processing, and idempotent acceptance requirements. This document defines how implementations demonstrate conformance to those requirements. It retains the independent-check conformance model introduced for JEP-Core 0.7 and makes the relationship between normative specifications, executable assertions, test artifacts, and reference implementations explicit. Conformance does not mean that an implementation has made a legal, policy, factual, authorization, causal, or external-target determination. It means that the implementation processes JEP events according to the declared JEP-Core version, validation mode, conformance class, explicitly active profiles, and applicable normative requirements. Where this document and JEP-Core conflict, JEP-Core controls.

Normative Precedence and Derived Artifacts JEP-Core is the normative source for JEP-Core semantics. This document defines conformance structures and testing conventions for evaluating those semantics; it does not independently redefine JEP-Core. Schemas, conformance assertions, test vectors, executable test suites, examples, reference implementations, command-line tools, generated reports, and interoperability reports are derived artifacts. A derived artifact MUST NOT introduce a JEP-Core normative requirement that is absent from the applicable normative specification. A derived artifact MAY encode, exercise, or operationalize an existing normative requirement. A test assertion SHOULD identify the normative specification source from which its expected behavior is derived. A reference implementation MUST NOT be treated as an independent source of JEP-Core semantics. Where a derived artifact conflicts with the applicable normative specification, the normative specification controls. Implementation behavior, even when shared by multiple implementations, does not by itself create a new JEP-Core requirement. Profile-specific behavior is normative only within the explicitly selected profile or profile composition that defines that behavior.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Conformance Model

Independent Checks JEP-Core 0.7 does not define cumulative validation levels. A conforming validator reports independent checks. Core-defined checks are:

• syntax
• cryptographic
• event_identity
• reference_integrity
• extension_processing

Trust- or acceptance-profile checks include:

• actor_binding
• freshness
• audience

Companion or external checks include:

• chain_integrity
• policy

A check status is one of:

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

An implementation MUST NOT report an unperformed check as pass. An implementation MUST NOT convert unsupported, indeterminate, or not_checked into pass merely to produce a successful overall result.

Overall Status For the requested validation mode and active profile set, the overall status is one of:

• valid
• invalid
• indeterminate

valid means that all checks required by the active validation context passed or were not applicable. invalid means that at least one required check failed. indeterminate means that no required check failed, but at least one required check could not produce a determinate result because it was unsupported, lacked required evidence or state, or otherwise remained indeterminate. Checks not required by the requested mode or active profile set MAY be not_checked. A successful cryptographic check alone MUST NOT cause the overall result to be valid when another required check has failed or is indeterminate.

Validation Modes The initial validation modes are:

• archival
• acceptance
• chain
• policy

Archival validation is repeatable and MUST NOT consume acceptance state. Acceptance validation includes JEP-Core Event Identity and idempotent acceptance semantics plus any profile-required actor-binding, freshness, audience, challenge, or equivalent checks. Chain and policy modes invoke companion or external semantics. A Core implementation MUST NOT present a chain or policy result as an intrinsic JEP-Core property. When profile selection is governed by the JEP profile model , the active profile set for a validation operation MUST be explicit. A validator MUST NOT silently substitute a different profile merely because validation under the explicitly selected profile failed.

Conformance Classes

JEP-Core-0.7 Producer A producer conforms to JEP-Core-0.7 Producer if it supports:

• I-JSON-compatible event construction as defined by ;
• a stable id for each event instance;
• all required top-level Core members;
• J/D/T/V verb-specific Core requirements;
• JCS canonicalization of the unsigned event as defined by ;
• signature generation under at least one declared signature conformance class;
• algorithm-tagged digest strings;
• ext and ext_crit semantics.

A conforming producer MUST NOT reuse one Event Identity (who,id) for different unsigned event content. A producer MUST NOT present Event Hash as the stable Event Identity.

JEP-Core-0.7 Verifier A verifier conforms to JEP-Core-0.7 Verifier if it supports:

• duplicate JSON member rejection;
• Core field and verb-specific validation;
• Event Identity validation;
• JCS canonicalization as defined by ;
• signature verification under at least one declared signature conformance class, using where that class is JWS-based;
• Event Hash calculation;
• independent validation checks;
• structured validation-result objects;
• unknown critical-extension rejection;
• archival validation mode.

A Core verifier MUST NOT require an optional identity, credential, attestation, blockchain, AI-platform, agent-framework, challenge, transport, chain, policy, archival, or vendor-specific profile for Core conformance. A verifier MUST NOT claim a check passed if the operation represented by that check was not performed.

JEP-Core-0.7 Acceptance Processor An implementation claiming JEP-Core-0.7 Acceptance Processor conformance MUST additionally support:

• a stable acceptance-domain definition;
• detection of conflicting Event Identity reuse;
• sufficient acceptance state for the claimed acceptance lifetime;
• atomic or equivalent first-acceptance processing;
• accepted, already_accepted, rejected, and indeterminate outcomes;
• separation of repeated valid delivery from invalid event content.

The same Event Identity MUST NOT apply the same acceptance effect more than once within one acceptance domain. A repeated valid event MUST NOT be converted into a cryptographic or syntax failure solely because it was previously accepted. If the processor cannot reliably determine whether an Event Identity has already produced the protected effect, it MUST NOT claim a fresh accepted outcome.

JEP-Extension-0.7 Processor An extension processor conforms to JEP-Extension-0.7 Processor if it can:

• locate extension objects under ext;
• process identifiers named by ext_crit;
• fail extension_processing for unknown critical extensions;
• ignore unknown non-critical extensions where Core permits this;
• detect conflicting critical extensions;
• preserve JEP-Core member semantics.

An implementation MUST NOT treat an unknown critical extension as a warning while continuing to report the applicable extension_processing requirement as successful.

JEP-Baseline-Ed25519-JWS-JCS-0.7 This document defines an interoperable baseline conformance class named JEP-Baseline-Ed25519-JWS-JCS-0.7. It requires:

• I-JSON-compatible JSON as defined by ;
• JCS canonicalization as defined by ;
• detached JWS Compact Serialization as defined by ;
• the fully specified JOSE alg value Ed25519 defined by ;
• Ed25519 signature processing as defined by ;
• algorithm-tagged sha256 digest strings;
• Event Hash calculation over the full signed event object including sig.

For this baseline, the JWS Payload is exactly the JEP Signing Payload: the UTF-8 octets of the RFC 8785 JCS-canonicalized unsigned event. The protected JOSE header MUST contain: A kid parameter MAY be present. If present, kid MUST be carried in the protected header. Additional protected parameters MAY be present when allowed by the active trust profile. A verifier MUST process every critical JOSE header parameter that it is required to understand under . This baseline uses the ordinary base64url-encoded JWS Payload semantics of . Producers MUST NOT use b64:false for this conformance class. The JWS Signing Input is exactly: The top-level JEP sig member MUST contain the detached JWS Compact Serialization form: The middle payload segment is empty only in the transmitted detached serialization. During verification, the verifier reconstructs the signing input using the exact JEP Signing Payload. Base64url segments MUST use the RFC 7515 encoding rules, including omission of = padding and absence of whitespace. The JWS Compact Serialization has no unprotected JOSE header. This baseline therefore does not permit security-relevant signature parameters to be carried outside the protected header. Conformance vectors for this baseline MUST publish:

• the complete unsigned event;
• the exact JEP Signing Payload bytes, encoded in a transport-safe form;
• the protected-header JSON;
• the protected-header base64url segment;
• the detached sig string;
• the resulting full signed event;
• the Event Hash;
• the expected validation result.

A producer is not required to serialize semantically equivalent protected-header JSON into identical bytes outside a vector that explicitly claims byte-for-byte reproduction. A verifier MUST verify the exact protected-header segment carried by the JWS. This baseline is a conformance-class requirement, not a restriction on JEP-Core algorithm agility.

Profile-Specific Conformance A profile MAY define additional conformance classes. Such classes MUST state:

• which validation checks are required;
• which checks are optional;
• which identifiers, credentials, attestations, or evidence are required;
• which algorithms are accepted or prohibited;
• whether freshness, audience, challenge-response, nonce, counter, sequence, transaction, ledger, or other replay-related mechanisms are required;
• how unsupported or indeterminate evidence is reported;
• any acceptance-domain requirements.

Profiles MUST NOT redefine JEP-Core Event Identity, Event Hash, J/D/T/V, signing-payload, or Core check semantics. When an implementation claims conformance to the explicit profile-selection model defined by , failure under one explicitly selected profile MUST NOT cause a verifier or test harness to silently retry another profile and report success under the original validation request.

Historical Decoder Capability Support for JEP encodings predating Core -07 is OPTIONAL and is not part of JEP-Core-0.7 conformance. An implementation advertising a historical decoder MUST name that decoder explicitly. It MUST NOT select a historical decoder by first failing JEP-Core 0.7 validation and then inferring an older draft format solely from field presence. Historical signed events MUST NOT be rewritten or silently upgraded.

Validation Result Object A conforming verifier SHOULD return a structured validation result.

Valid Archival Example

Safe Retry Example

Signature Failure Example

Result Requirements A conformance result object MUST distinguish:

• overall status;
• requested mode;
• active profile or explicitly selected profile set;
• Event Identity when available;
• Event Hash when calculated;
• independent checks;
• acceptance outcome when acceptance mode produces an outcome;
• warnings;
• errors.

The event_identity member reports the (who,id) values asserted by the parsed event. Its presence does not by itself establish signature validity, actor binding, authority, freshness, or non-conflicting historical use of that Event Identity. The event_identity check reports only the JEP-Core Event Identity checks actually performed, including conflicting reuse detection when identity state is available. It MUST NOT be used as a substitute for cryptographic or actor_binding. Similarly, an event_hash member reports the digest calculated for an exact signed artifact. Its presence does not establish actor binding, substantive truth, authorization, policy acceptance, or external effect. An error object SHOULD contain a JEP failure code, the associated check when applicable, and an explanatory message. A result MUST NOT contain a cumulative validation level.

Acceptance Outcome Consistency When mode is acceptance, the result MUST contain an acceptance object once the acceptance processor has produced an outcome. The outcome and overall status MUST be consistent as follows:

Acceptance outcome	Overall status	effect_applied
accepted	valid	true
already_accepted	valid	false
rejected	invalid	false
indeterminate	indeterminate	false

accepted means all checks required by the active acceptance context passed or were not applicable and the acceptance effect is applied for the first time. already_accepted means the event is valid for the active acceptance context but the same Event Identity has already applied that effect in the same acceptance domain. rejected means at least one required validation check failed. indeterminate means no required validation check failed, but the acceptance processor could not complete a required determination because required evidence, implementation support, durable state, or atomicity guarantees were unavailable. effect_applied MUST be true only for accepted. A verifier MUST NOT report already_accepted as a cryptographic or syntax failure. For non-acceptance modes, the acceptance member SHOULD be absent unless a companion result format explicitly carries a separately labeled acceptance observation.

JSON Schema Requirements The conformance suite SHOULD provide:

• jep-event-0.7.schema.json
• jep-ref-0.7.schema.json
• jep-extension-0.7.schema.json
• jep-validation-result-0.7.schema.json
• schemas for any baseline signature or profile objects defined by the suite

JSON Schema validation does not prove cryptographic validity, actor binding, freshness, reference resolution, policy compliance, or external truth. Duplicate-member rejection occurs before ordinary parsed-object schema validation. Schemas are derived artifacts. A schema MUST NOT intentionally impose a JEP-Core requirement absent from JEP-Core. Where a schema and the applicable normative specification conflict, the normative specification controls.

Minimal Event Schema Seed The following schema is a structural seed. It intentionally does not attempt to encode every JEP semantic rule. The schema does not make nonce a Core field. A nonce or equivalent mechanism MAY appear in a registered extension, profile-defined object, transport binding, or other non-Core layer.

Typed JEP Event Reference Seed A logical JEP event reference SHOULD use Event Identity: An exact signed artifact MAY additionally be pinned: The value identifies the logical event. The optional hash identifies one exact signed artifact. Event Hash MUST NOT replace Event Identity where logical event identity is required.

Reference Validation Flow A reference validator SHOULD process an event in an order equivalent to: An implementation MUST perform cryptographic validation before writing new authoritative Event Identity or acceptance state for untrusted input. When the active acceptance profile requires actor binding, an implementation MUST NOT commit authoritative Event Identity or acceptance state until actor_binding has passed. A verifier MUST NOT treat a transport retry as creation of a new event. A verifier operating under an explicit profile-selection model MUST NOT select a different trust or acceptance profile merely because validation under the explicitly active profile produced failure, unsupported, or indeterminate results.

Test Vector Categories

Valid Core Event Vectors The suite SHOULD include:

• valid/J-basic.json
• valid/D-basic.json
• valid/T-basic.json
• valid/V-basic.json
• valid/event-reference-logical.json
• valid/event-reference-exact-artifact.json

Syntax and Core-Field Vectors The suite SHOULD include:

• invalid/invalid-json.json
• invalid/duplicate-member.json
• invalid/missing-id.json
• invalid/invalid-what.json
• invalid/unknown-verb.json
• invalid/invalid-timestamp.json
• invalid/D-missing-delegatee.json
• invalid/D-missing-scope.json
• invalid/T-missing-ref.json
• invalid/T-missing-termination-scope.json
• invalid/V-missing-ref.json
• invalid/V-missing-verification-scope.json
• invalid/V-missing-result.json

Cryptographic Vectors The suite SHOULD include:

• invalid/invalid-signature.json
• invalid/signature-over-wrong-payload.json
• invalid/unsupported-signature-alg.json
• invalid/prohibited-signature-alg.json
• invalid/alg-key-type-mismatch.json
• invalid/alg-profile-mismatch.json
• invalid/canonicalization-failed.json
• invalid/canonicalization-version-unsupported.json

Event Identity and Delivery Vectors Event Identity behavior is stateful. A single isolated JSON event cannot by itself demonstrate conflicting reuse or prior acceptance. The suite SHOULD therefore include stateful sequence manifests such as:

• stateful/event-identity-retransmission.json
• stateful/event-identity-resign-same-content.json
• stateful/event-id-conflict.json
• stateful/same-id-different-who.json

A stateful manifest SHOULD declare the identity or acceptance state visible to the harness, the ordered steps, and the expected result for each step. The second event in the example uses the same (who,id) but different JCS-canonicalized unsigned event content. The suite SHOULD also verify:

• retransmission of byte-identical signed content;
• re-signing of identical unsigned content with the same Event Identity;
• use of the same id string under a different who;
• conflicting reuse of one Event Identity with different unsigned content.

Conflicting reuse MUST produce ERR_EVENT_ID_CONFLICT. A valid repeated event MUST NOT be reported as a cryptographic failure.

Acceptance Vectors Acceptance behavior is stateful. The suite SHOULD include:

• stateful/accept-first.json
• stateful/accept-safe-retry.json
• stateful/accept-state-unavailable.json
• stateful/accept-atomicity-unavailable.json
• a concurrent first-delivery test

A safe-retry sequence SHOULD demonstrate that the first valid delivery yields accepted with effect_applied: true and a later valid delivery of the same Event Identity in the same acceptance domain yields already_accepted with effect_applied: false. If required acceptance state is unavailable, the result MUST NOT claim a fresh accepted outcome. It MUST be indeterminate or rejected when an active profile explicitly requires fail-closed rejection. If required atomicity cannot be provided, the implementation MUST NOT claim accepted. When represented as a JEP failure code, the suite SHOULD exercise ERR_ACCEPTANCE_ATOMICITY_UNAVAILABLE. The concurrent first-delivery test SHOULD submit multiple equivalent deliveries of the same Event Identity against one acceptance domain and assert that exactly one state-changing acceptance effect is applied. All other valid deliveries MUST be reported without a second effect, normally as already_accepted. Nonce, challenge, sequence-number, counter, ledger, or similar replay tests belong to the profile that requires that mechanism and MUST NOT be presented as universal JEP-Core requirements.

Reference Vectors The suite SHOULD include:

• logical Event Identity resolution;
• exact-artifact hash success;
• exact-artifact hash mismatch;
• Event Identity mismatch;
• unresolved references when a requested check requires resolution.

Extension Vectors The suite SHOULD include:

• known critical extension success;
• unknown critical extension failure;
• unknown non-critical extension tolerance;
• extension schema failure;
• conflicting critical extensions.

A vector for an unknown critical extension MUST NOT expect extension_processing: pass. A test harness MUST NOT convert an unknown critical extension into a successful Core result merely because the implementation emitted only a warning.

Canonicalization and Hash Vectors The suite SHOULD include:

• equivalent JSON inputs producing identical JCS bytes;
• UTF-16 property-order edge cases required by JCS;
• numeric serialization edge cases allowed by I-JSON/JCS;
• full signed Event Hash calculation;
• unsigned JEP Signing Payload calculation;
• proof that changing sig can change Event Hash without changing Event Identity.

Companion and External Check Vectors Chain and policy fixtures MAY be included for integration testing, but they MUST identify the companion profile, companion specification, or external evaluator that owns the semantics. They MUST NOT be labeled as Core-only conformance failures. External truth, legal effect, authority, policy, or causal conclusions MUST NOT be inferred solely from successful Core conformance.

Historical Compatibility Vectors If a product advertises a historical pre--07 decoder, the suite SHOULD include:

• explicit historical decoder selection;
• historical signature verification without rewriting bytes;
• refusal to silently fall back from 0.7 based solely on field presence.

The suite SHOULD include a case in which Core 0.7 validation fails but the harness MUST NOT automatically retry a historical decoder.

Profile Selection and Downgrade Vectors For implementations that claim the explicit profile-selection behavior defined by , the suite SHOULD include:

• explicit profile selection;
• unsupported explicitly selected profile;
• failed explicitly selected profile;
• multiple explicitly composed profiles where composition is defined;
• conflicting profile requirements;
• prohibited algorithm under the active profile;
• failure under one profile without silent fallback to another profile;
• event content that could heuristically suggest a different profile but for which that profile was not explicitly selected.

A conforming profile-aware verifier MUST NOT infer successful validation under a different profile merely because who resembles an identifier associated with that profile, a credential associated with another profile is present, aud resembles another deployment, a nonce-like or challenge-like extension is present, or the explicitly selected profile failed. A profile-selection test MUST identify the profile-selection input visible to the implementation. The suite MUST distinguish profile-selection behavior from JEP-Core event semantics.

Seed J/D/T/V Event Shapes The following examples use placeholder signatures. They are examples and are not substitutes for signed conformance vectors.

J-basic

D-basic

T-basic

V-basic

Conformance Test Assertions A stateless test assertion SHOULD name:

• a stable assertion identifier;
• the input event;
• the requested validation mode;
• the explicitly active profile or profile set;
• the applicable normative source or sources;
• the expected overall status;
• the expected independent checks;
• expected warnings and errors;
• the expected Event Hash when applicable.

An assertion_id identifies an assertion within a conformance suite. An assertion identifier does not itself create a protocol requirement. An assertion SHOULD identify the normative specification section from which the expected behavior is derived. A stateful test MUST declare the state scope and ordered operations required to obtain the expected result. It SHOULD use an explicit steps array rather than imply state through a filename. A concurrency assertion SHOULD additionally declare the number of concurrent deliveries and MUST assert the number of state-changing effects observed by the harness. Test assertions MUST NOT use expected_level for JEP-Core 0.7. A conformance harness MUST distinguish:

• validation output returned by the verifier;
• state supplied to the verifier;
• state committed by the acceptance processor;
• externally observed effect count used to test atomicity.

This distinction prevents a test harness from reporting at-most-once acceptance merely because it deduplicated test inputs before invoking the implementation under test.

Normative Coverage A conformance suite SHOULD document its coverage of machine-testable normative requirements. For each machine-testable normative requirement that the suite claims to cover, the suite SHOULD identify one or more assertions exercising that requirement. A coverage record MAY classify requirements as covered, partially_covered, not_machine_testable, or out_of_scope. A requirement MUST NOT be labeled covered solely because a related example or implementation test exists. Where part of a requirement depends on external truth, policy, trust, resolver behavior, or other semantics outside Core, the Core-testable portion SHOULD be distinguished from the external portion. A requirement that is not machine-testable at the Core layer SHOULD be identified as such rather than represented by a misleading executable test. Test count by itself is not evidence of normative coverage. A suite claiming complete machine-testable Core coverage SHOULD disclose the number of applicable machine-testable requirements, covered requirements, partially covered requirements, and uncovered requirements. A suite SHOULD NOT claim complete machine-testable coverage when an applicable machine-testable normative requirement remains uncovered.

Assertion Stability An assertion identifier SHOULD remain stable across suite releases when the semantic assertion is unchanged. If expected normative behavior changes because the applicable specification changes, the suite SHOULD issue a new or versioned assertion rather than silently changing the meaning of an existing published assertion. Editorial corrections that do not change expected behavior MAY retain the assertion identifier.

Reference CLI Behavior A reference implementation is non-normative. Its purpose is to demonstrate one implementation of the applicable specifications and to execute public conformance artifacts. Implementation-specific behavior MUST NOT become a JEP-Core conformance requirement unless that requirement is independently specified by an applicable normative specification. A reference implementation SHOULD provide equivalent operations to: A chain-specific command MAY be provided by a companion validator. Its result MUST remain distinguishable from JEP-Core validation. CLI output SHOULD use the structured result object defined in this document. If reference implementation behavior conflicts with the applicable normative specification, the implementation behavior is a defect or requires specification clarification; it does not silently amend the specification.

Implementation Disclosure and Interoperability Reports A conforming implementation SHOULD document:

• supported JEP-Core release;
• supported conformance classes;
• supported validation modes;
• supported independent checks;
• supported signature algorithms and canonicalization rules;
• supported hash algorithms;
• supported trust and acceptance profiles;
• supported extensions;
• acceptance-state durability and atomicity assumptions;
• historical decoder capabilities, if any;
• conformance-suite identity;
• conformance-suite version;
• conformance-suite digest;
• test-vector results.

An interoperability report MAY use: The suite digest identifies the exact suite artifact or suite manifest used by the report. Two reports SHOULD NOT be treated as directly comparable merely because they report the same number of passing tests. For direct comparison, reports SHOULD identify the same applicable JEP-Core version, conformance class, suite version, suite digest, validation mode, and profile set. A report MUST NOT imply support for checks, profiles, modes, extensions, or conformance classes that were not actually exercised or otherwise demonstrated. A report MUST NOT present successful Core conformance as proof of external truth, legal validity, authorization validity, policy compliance, causality, or external effect. A suite digest establishes artifact identity. It does not establish that the suite itself is correct or normative.

Security Considerations A conformance suite can detect specified classes of implementation divergence but cannot prove deployment security. Implementations MUST verify untrusted cryptographic input before committing authoritative Event Identity or acceptance state. When actor binding is required for acceptance, actor binding MUST pass before such state is committed. Acceptance processors MUST provide atomic or equivalent concurrency guarantees for first acceptance. A check-then-apply-then-mark sequence that can race is non-conforming. Acceptance-state retention MUST be sufficient for the period during which an event remains eligible to produce the protected effect. Event IDs are not secrets, bearer tokens, authorization grants, or freshness proofs. A valid signature does not prevent repeated delivery. Deployments requiring current liveness, strict ordering, server challenge freshness, or single-use authority SHOULD use an appropriate profile mechanism in addition to JEP-Core. Implementations MUST reject algorithms prohibited by the active profile and MUST NOT silently downgrade to weaker algorithms. Profile-aware validators MUST NOT silently switch profiles after failure of an explicitly active profile when the applicable profile model requires explicit selection. Unknown critical extensions MUST NOT be converted into successful validation merely because the implementation can otherwise continue processing. Test keys and test credentials MUST NOT be used in production. Incorrect test artifacts can cause false conformance conclusions. Test-suite maintainers therefore SHOULD preserve provenance between assertions and the normative requirements they exercise. Reference implementations and test suites SHOULD be independently reviewable. No reference implementation, test suite, registry, vendor product, or maintainer is by itself a source of JEP-Core semantics.

Privacy Considerations Test vectors SHOULD use synthetic identifiers and non-sensitive claims. Event IDs, Event Hashes, actor identifiers, references, validation reports, profile identifiers, and interoperability reports can enable correlation. Conformance fixtures SHOULD avoid unnecessary stable real-world identifiers. Exact-artifact hashes may permit correlation or confirmation attacks. Sensitive evidence SHOULD be represented using profile-appropriate privacy mechanisms rather than copied into public conformance vectors. Conformance reports SHOULD disclose only the implementation metadata required to establish the interoperability claim being made. Normative-source references and assertion identifiers SHOULD NOT embed personal or deployment-secret information.

Versioning and Historical Compatibility The conformance suite MAY version its executable artifacts independently from the Internet-Draft revision. A new executable suite release does not by itself create a new JEP-Core version. Artifacts claiming JEP-Core 0.7 conformance MUST use the JEP-Core 0.7 event model and validation model defined by this document and the companion Core draft. The wire major remains jep: "1" for JEP-Core 0.7. Pre--07 Internet-Draft encodings that also used jep: "1" are historical draft artifacts and MUST NOT be selected by heuristic fallback. Historical signed bytes MUST NOT be rewritten to satisfy a newer conformance suite. A new conformance-suite version MAY add assertions for existing normative requirements, improve coverage, add adversarial cases, fix incorrect derived artifacts, or add interoperability metadata. A suite update MUST NOT silently change a JEP-Core normative requirement. If an earlier test assertion is discovered to contradict the applicable normative specification, the suite SHOULD correct the assertion and document the correction. Such correction does not modify the normative specification. A future Core revision that changes stable Event Identity, signing-input, canonicalization, or required Core-field semantics after real-world wire adoption may require a new wire major as specified by JEP-Core.

Changes from -01 Major changes from draft-wang-jep-conformance-01:

• clarified normative precedence between JEP-Core, this conformance specification, derived test artifacts, and reference implementations;
• explicitly stated that test suites, schemas, examples, reference implementations, and interoperability reports do not independently create JEP-Core semantics;
• required derived artifacts not to introduce JEP-Core requirements absent from the applicable normative specification;
• added stable conformance assertion identifiers and normative-source references to the assertion model;
• added normative coverage guidance for machine-testable requirements and clarified that test count alone is not evidence of normative coverage;
• added guidance for assertion stability across executable suite releases;
• explicitly stated that reference implementations are non-normative;
• added profile-selection and downgrade vectors for implementations claiming the explicit profile-selection model;
• strengthened guidance for unknown critical extensions, unperformed checks, historical decoder fallback, and profile inference;
• added conformance-suite name, version, and digest to the recommended interoperability report and clarified when reports are directly comparable;
• clarified that a suite digest establishes artifact identity but not normative authority;
• retained the JEP-Core 0.7 wire model, Event Identity, Event Hash, J/D/T/V semantics, validation-check model, extension semantics, baseline signing class, and idempotent acceptance semantics unchanged.

IANA Considerations This document requests no IANA actions.

Normative References

Acknowledgments The author thanks implementers and reviewers who provided interoperability, security, and deployment feedback on earlier JEP drafts and conformance revisions.