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

JAC JEP dependency chains This document defines JAC-2, a minimal declared-dependency graph profile for the Judgment Event Protocol (JEP) . JAC-2 binds a signed JEP event to zero or more declared parent dependencies through one critical JEP extension. JEP Event Identity is used for logical JEP event dependencies; Event Hash is used only when an exact signed artifact must also be pinned. Digest-addressed receipt or external records can be linked without becoming JEP events. JAC-2 defines dependency-link structure, partial-fragment semantics, cycle handling, chain validation checks, and non-inference boundaries. It does not determine factual causality, responsibility, fault, authorization validity, workflow correctness, legal effect, or regulatory compliance.

Introduction Agent and automated systems often produce signed events whose interpretation depends on earlier events, records, tool outputs, receipts, or other digest-addressed artifacts. JEP-Core intentionally does not define causal-chain or dependency-graph semantics. JAC provides one optional chain profile for that purpose. The narrow JAC question is: A declared dependency is not a protocol-level finding of real-world causality. JEP Profiles defines profile selection and composition rules. JEP Conformance defines structured validation and test-harness conventions. JEP Receipt Profile defines a portable receipt format that MAY be referenced by digest from JAC. Where this document conflicts with JEP-Core, JEP-Core controls.

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.

Scope and Terminology

JAC-2 Defines JAC-2 defines:

• one profile identifier;
• one critical dependency extension;
• zero-or-more parent links per JEP event;
• logical JEP-event parent references using Event Identity;
• optional exact-artifact pinning using Event Hash;
• digest-addressed non-JEP parent references;
• partial-fragment and unresolved-parent semantics;
• cycle detection for resolved dependency fragments;
• independent JAC validation checks;
• dependency-graph validation result semantics.

JAC-2 Does Not Define JAC-2 does not define:

• new JEP verbs;
• a new event format;
• a new signature or hash format;
• a replacement for Event Identity or Event Hash;
• automatic delegation, authorization, or termination propagation;
• factual causality;
• complete real-world history;
• responsibility, fault, negligence, intent, fairness, or entitlement;
• task, workflow, state-machine, handoff, or result semantics;
• legal liability or regulatory compliance;
• a mandatory bundle, transport, archive, or ledger.

Declared Dependency A signed statement that the current JEP event depends on or is based on an identified parent according to the relation semantics selected for the link. The baseline relation defined by JAC-2 is declared-dependency.

Parent The object referenced by one JAC dependency link. A parent MAY be:

• a JEP event identified by Event Identity;
• a digest-addressed receipt record;
• another digest-addressed external record.

Dependency Fragment A set of JEP events and referenced parent objects observed together for JAC validation. A Dependency Fragment is partial by default. JAC retains the term "chain" for continuity, but the JAC-2 baseline data model is a directed dependency graph: it MAY branch and join because an event can declare zero or more parents.

Resolved Parent A parent for which the verifier has obtained the referenced object or exact artifact needed by the requested validation context.

Unresolved Parent A syntactically valid parent reference for which the referenced object is not available or cannot be resolved in the requested validation context. An unresolved parent is not proof that the parent does not exist.

Profile and Extension Identifiers

JAC-2 Profile Identifier The profile identifier is: The human-readable label JAC-2 MAY be used in documentation. The identifier is a publisher-controlled HTTPS URI. Dereferencing it is not required for validation.

Dependency Extension Identifier The dependency extension identifier is: A JEP event claiming JAC-2 conformance MUST carry this extension in ext and MUST list the extension identifier in ext_crit. A verifier that cannot process this critical extension cannot claim successful JAC-2 validation.

Version Boundary JAC-2 is not wire-compatible with JAC-Core-1 from draft-wang-jac-02. JAC-Core-1 used a single digest-oriented based_on link and commonly treated JEP Event Hash as the parent-event reference. JAC-2 instead supports multiple parents and uses Event Identity for logical JEP event references. Historical JAC-Core-1 events MUST NOT be silently rewritten as JAC-2 events.

Relationship to JEP-Core JAC-2 relies on JEP-Core for:

• the signed event object;
• J/D/T/V semantics;
• Event Identity (who,id);
• Event Hash;
• the JEP Signing Payload;
• signature validation;
• ref;
• ext and ext_crit;
• independent validation checks;
• validation modes;
• idempotent acceptance.

JAC-2 MUST NOT redefine any of those semantics. A JAC dependency link is separate from JEP ref. JEP ref retains the meaning defined by JEP-Core. The JAC dependency extension declares graph edges used by JAC chain processing. An implementation MUST NOT infer a JAC dependency solely from JEP ref. A deployment MAY use both JEP ref and JAC parent links in one event.

JAC Dependency Extension

Extension Shape The JAC-2 dependency extension MUST be a JSON object containing:

• profile
• parents

profile MUST equal https://humanjudgment.org/jep/profiles/jac/2. parents MUST be a JSON array containing zero or more Parent Link objects. An empty parents array declares that the event is a JAC root in the observed dependency structure. It does not prove that the event had no external predecessors in the real world. No other members are defined by the JAC-2 baseline extension. The order of entries in parents has no semantic meaning.

Parent Link A Parent Link MUST be a JSON object containing:

• relation
• parent

relation MUST equal declared-dependency for the JAC-2 baseline. parent MUST be a Parent Reference defined in Section 6.3. A future profile MAY define additional relation identifiers. Such identifiers MUST be absolute URIs, MUST be collision-resistant, and MUST define:

• exact edge semantics;
• required parent fields;
• graph-processing rules;
• cycle rules if different from JAC-2;
• non-inference boundaries.

An additional relation MUST NOT silently redefine declared-dependency.

Parent Reference A Parent Reference MUST be a JSON object containing kind. kind MUST be one of:

• jep-event
• digest-record

JEP Event Parent When kind is jep-event, the Parent Reference MUST contain event_identity. event_identity MUST be an object containing non-empty string members who and id. The Parent Reference MAY additionally contain:

• event_hash
• uri

event_hash, when present, MUST be a valid JEP algorithm-tagged digest string and pins one exact signed artifact for the identified event. uri, when present, is a retrieval hint only. The logical dependency node is Event Identity, not Event Hash. A verifier MUST NOT create two logical JAC nodes merely because two valid signed artifacts for the same Event Identity have different Event Hash values. If the same Event Identity resolves to conflicting unsigned JEP event content, JEP Event Identity conflict processing applies and JAC dependency-graph validation MUST NOT report success. Digest Record Parent When kind is digest-record, the Parent Reference MUST contain digest. digest MUST be an algorithm-tagged digest string. The Parent Reference MAY additionally contain:

• profile
• record_type
• media_type
• uri

If present, profile MUST be an absolute URI, record_type and media_type MUST be non-empty strings, and uri MUST be an absolute URI. These members are descriptive and MUST NOT replace digest integrity. If profile equals https://humanjudgment.org/jep/profiles/receipt/1, the referenced record is claiming the JEP Receipt Profile namespace. A verifier MUST NOT claim Receipt Profile validity unless that record was separately validated under the applicable Receipt Profile rules.

Duplicate Parent Links Within one dependency extension, two Parent Links MUST NOT identify the same logical parent under the same relation. For jep-event, logical equality is Event Identity equality. For digest-record, logical equality is exact digest-string equality. A producer MAY refer to the same logical parent under two different profile-defined relations only when the semantics of those relations require that distinction.

Self-Dependency A JAC event MUST NOT contain a jep-event parent whose Event Identity equals the current event's Event Identity. A self-dependency is a JAC structural failure.

Examples

JAC Root

Single JEP Parent

Multiple Parents with Exact Artifact Pin The second example fragment is the extension value only.

Dependency Graph Semantics

Direction Each Parent Link creates a directed edge: declared parent ]]> The edge means only that the current event declares the parent as a dependency under the stated relation. It does not, by itself, mean that the parent caused the current event.

Multiple Parents A JAC event MAY declare multiple parents. Multiple parents do not imply equal weight, joint sufficiency, complete input coverage, or causal exhaustiveness. JAC-2 does not define a parent ordering.

Roots An event with an empty parents array is a declared JAC root. Root status is local to the declared JAC dependency structure. A root declaration MUST NOT be interpreted as proof that no earlier real-world event, input, instruction, or cause existed.

Acyclicity The baseline declared-dependency relation is acyclic. A resolved dependency fragment containing a directed cycle under declared-dependency is invalid under JAC-2. Cycle detection operates on logical JEP Event Identity nodes and digest-record digest identities. An unresolved parent cannot by itself prove that a cycle exists or does not exist outside the observed fragment.

Partial Observation JAC-2 uses an open-world, partial-fragment default. A valid observed fragment does not imply that:

• all parents were disclosed;
• all relevant events were observed;
• all real-world causes were represented;
• the fragment is a complete chain;
• the declared root is a real-world first cause.

A profile claiming complete-log or closed-world semantics MUST define those assumptions explicitly.

Unresolved Parents An unresolved parent reference MAY remain structurally valid. Whether unresolved parent resolution is required depends on the requested validation context. A verifier MUST NOT convert an unresolved parent into a fabricated success, missing-parent fault, or proof of non-existence.

Receipt and External Record Dependencies A JAC digest-record parent is identified by digest. JAC verifies only the properties requested by the JAC validation context. Digest equality establishes integrity identity for the referenced record; it does not establish the truth or sufficiency of that record. If a referenced record declares another profile, such as JEP Receipt Profile, that profile's validity MUST be reported separately from JAC status. JAC MUST NOT convert Receipt Profile validity into causal validity, authorization validity, or completeness.

Validation Model

Layer Separation A JAC validation result separates:

• underlying JEP validation status;
• JAC profile checks;
• JAC overall status;
• fragment completeness statement.

JAC MUST NOT overwrite the JEP validation result.

Validation Contexts JAC-2 defines two profile validation contexts:

• link
• fragment

link validates one event's dependency extension and parent-reference structure. Parent resolution is not required unless exact artifact integrity is explicitly requested. fragment validates an observed multi-node dependency fragment. It requires cycle analysis over all resolved in-scope nodes and evaluates parent integrity according to the requested fragment policy. A JEP implementation MAY invoke JAC fragment validation from JEP chain mode. JAC context names are profile-local and are not new JEP validation modes.

JAC Checks The initial JAC-2 check identifiers are:

• https://humanjudgment.org/jep/profiles/jac/2#profile-binding
• https://humanjudgment.org/jep/profiles/jac/2#dependency-extension
• https://humanjudgment.org/jep/profiles/jac/2#parent-reference
• https://humanjudgment.org/jep/profiles/jac/2#parent-resolution
• https://humanjudgment.org/jep/profiles/jac/2#parent-integrity
• https://humanjudgment.org/jep/profiles/jac/2#duplicate-parent
• https://humanjudgment.org/jep/profiles/jac/2#self-dependency
• https://humanjudgment.org/jep/profiles/jac/2#cycle
• https://humanjudgment.org/jep/profiles/jac/2#fragment-consistency
• https://humanjudgment.org/jep/profiles/jac/2#completeness-assumption

Check statuses use the JEP conformance vocabulary:

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

A verifier MUST NOT report an unperformed JAC check as pass.

Required Link Checks For link context, the required JAC checks are:

• profile-binding
• dependency-extension
• parent-reference
• duplicate-parent
• self-dependency

parent-resolution and parent-integrity are required only when the requested link-validation policy requires parent material or exact-artifact checking. cycle is not required for isolated link validation.

Required Fragment Checks For fragment context, the required checks are:

• all required link checks for every in-scope JAC event;
• parent-resolution for every parent that the requested fragment policy says must be resolved;
• parent-integrity for every resolved parent carrying an exact-artifact pin or digest-record reference;
• cycle;
• fragment-consistency;
• completeness-assumption.

If a required parent cannot be resolved and no required check has failed, JAC overall status is indeterminate. fragment-consistency passes only when each included JEP Event Identity maps to one non-conflicting unsigned event content, all resolved parent identities are consistent with their references, and multiple artifacts for one Event Identity are treated as one logical node. completeness-assumption passes when the verifier reports partial, or when an explicitly selected completeness profile authorizes complete-under-profile and all checks required by that profile pass.

Completeness Statement A JAC result MUST report one of:

• partial
• complete-under-profile

The default is partial. complete-under-profile MUST NOT be reported unless an explicitly selected profile defines the closed-world or complete-log assumptions and all required checks for those assumptions passed. JAC-2 alone never establishes real-world causal completeness.

JAC Overall Status The JAC overall status is one of:

• valid
• invalid
• indeterminate

For the requested JAC context:

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

valid does not mean causally true or complete.

Validation Procedure A fragment validator SHOULD:

• validate each in-scope JEP event under the requested JEP mode and profiles;
• process the critical JAC dependency extension;
• verify the JAC profile identifier;
• parse and validate all Parent Links;
• reject duplicate or self-dependencies;
• resolve required parent objects;
• verify Event Identity and optional Event Hash pins for JEP-event parents;
• verify digest integrity for available digest-record parents;
• construct the logical dependency graph;
• detect cycles over the resolved in-scope fragment;
• evaluate fragment consistency;
• evaluate the declared completeness assumption;
• return JEP results, JAC checks, JAC overall status, and completeness separately.

Validation Result Example The result does not assert factual causality or complete history.

Verification Events A JEP V event MAY record a JAC evaluation. The V event MUST satisfy JEP-Core V requirements. JAC-2 defines the following provisional profile-specific verification scopes:

• https://humanjudgment.org/jep/profiles/jac/2#link-validation
• https://humanjudgment.org/jep/profiles/jac/2#fragment-validation
• https://humanjudgment.org/jep/profiles/jac/2#parent-integrity
• https://humanjudgment.org/jep/profiles/jac/2#cycle-check

A V event MUST identify its target through JEP ref. what.result records the semantic result of the declared V scope. It MUST NOT be confused with the independent per-check status vocabulary used by a JAC validator. A V event MUST NOT imply chain completeness or causality beyond its declared scope.

Interaction with Delegation and Termination JAC dependency edges do not create authorization. A D event that also carries JAC dependency links remains a JEP Delegation statement. Whether the delegation is authorized belongs to the applicable delegation or mandate profile. A T event that also carries JAC dependency links remains a JEP Termination statement. JAC-2 does not define automatic termination cascade. If a chain or domain profile requires a parent termination to change child eligibility, that profile MUST define:

• which edge relations propagate the effect;
• which termination scopes are relevant;
• whether propagation is prospective or retrospective;
• how unresolved descendants are handled;
• how conflicting termination declarations are handled.

The existence of a JAC edge alone MUST NOT be treated as a termination propagation rule.

Optional Domain Semantics Earlier JAC revisions defined extension identifiers for state, assignment, handoff, results, capability claims, input/output references, and declared breaks. JAC-2 removes those items from the narrow waist. Such semantics MAY be defined by separate profiles or domain specifications, but they MUST NOT be inferred from the baseline declared-dependency relation. A domain profile defining additional dependency relations or adjacent metadata SHOULD specify:

• identifier namespace;
• data model;
• relation semantics;
• graph-processing rules;
• conflict handling;
• validation checks;
• security considerations;
• privacy considerations;
• non-inference boundaries.

Conformance

JAC-2 Producer A conforming JAC-2 Producer MUST:

• produce a JEP event conforming to the applicable JEP Producer requirements;
• include the JAC dependency extension;
• list it in ext_crit;
• use the JAC-2 profile identifier;
• use only defined Parent Reference forms;
• use Event Identity for logical JEP-event parents;
• use Event Hash only as an optional exact-artifact pin;
• reject self-dependency before signing;
• avoid duplicate parent links.

JAC-2 Link Verifier A conforming JAC-2 Link Verifier MUST:

• perform or consume an actual JEP validation result;
• process the critical dependency extension;
• perform all required link checks;
• preserve independent check statuses;
• distinguish Event Identity from Event Hash;
• return indeterminate rather than success when a required check cannot be completed.

JAC-2 Fragment Verifier A conforming JAC-2 Fragment Verifier MUST additionally:

• build graph nodes from logical Event Identity and digest-record identity;
• resolve parents required by the selected fragment policy;
• verify required exact-artifact and digest pins;
• detect baseline declared-dependency cycles;
• report fragment completeness explicitly;
• avoid inferring omitted parents or real-world causes from a valid fragment.

Security Considerations A valid JAC chain result does not establish factual causality. Implementations MUST consider:

• Event Identity/Event Hash confusion;
• duplicate or conflicting Event Identity reuse;
• self-dependency;
• dependency cycles;
• forged or substituted digest records;
• unresolved parents;
• omitted parents;
• selective export of a misleading fragment;
• profile confusion;
• unknown critical extensions;
• false complete-log assumptions;
• semantic inflation from dependency to causality;
• authorization inference from dependency;
• termination-cascade inference from dependency.

Exact artifact pins MUST be verified when required by the validation context. A verifier MUST NOT treat a URI retrieval location as integrity identity. A verifier MUST NOT convert missing or unavailable parent material into proof that no parent exists.

Privacy Considerations Dependency graphs can reveal:

• actor relationships;
• organizational structure;
• workflow topology;
• task dependencies;
• receipt relationships;
• tool or resource usage;
• timing and coordination patterns;
• hidden participants through correlation.

Implementations SHOULD minimize stable identifiers when they are not needed for interoperability. Digest references can still enable correlation and dictionary attacks. Partial exports MAY be used to reduce disclosure, but partial exports MUST NOT be presented as complete histories unless an applicable completeness profile supports that claim.

Non-Inference Boundary JAC-2 records declared dependency structure. A successful JAC validation MUST NOT be presented, by itself, as proof:

• that a declared dependency is a real-world cause;
• that all causes or parents were disclosed;
• that the fragment is complete;
• that a parent authorized a child;
• that a child correctly followed a parent;
• that a delegation chain is valid;
• that termination propagated;
• that an assignment or handoff was valid;
• that a result was correct;
• that responsibility, fault, or liability belongs to any actor;
• that a legal or regulatory requirement was satisfied.

External profiles MAY use JAC evidence when making such determinations, but those conclusions remain outside JAC-2.

IANA Considerations This document requests no IANA actions. The JAC-2 profile identifier, dependency-extension identifier, JAC check identifiers, and JAC verification-scope identifiers are publisher-controlled HTTPS URI identifiers. Future specifications MAY define registries if deployment experience shows that a stable shared registry is needed.

Changes from -02 Major changes from draft-wang-jac-02:

• aligned JAC with JEP-Core 0.7, JEP Profiles-01, and JEP Conformance-01;
• removed the HJS technical dependency from JAC-Core and aligned optional receipt references with JEP Receipt Profile;
• introduced JAC-2 as an incompatible profile revision;
• replaced https://jac.org/chain with publisher-controlled JEP namespace identifiers;
• replaced the single based_on field with a parents array supporting zero or more parent dependencies;
• changed logical JEP parent identity from Event Hash to Event Identity;
• retained Event Hash only as optional exact signed-artifact pinning;
• introduced explicit jep-event and digest-record Parent Reference forms;
• defined empty parents as a declared JAC root without claiming a real-world first cause;
• prohibited duplicate parent links and self-dependency;
• defined baseline dependency direction and acyclicity;
• defined open-world partial-fragment semantics;
• defined unresolved-parent behavior;
• defined link and fragment validation contexts without creating new JEP validation modes;
• defined independent JAC checks and valid / invalid / indeterminate result semantics;
• added explicit partial versus complete-under-profile completeness reporting;
• removed state, assignment, handoff, result, capability, input/output, and declared-break extensions from the JAC narrow waist;
• removed nonce and legacy replay assumptions;
• removed examples that used pre-0.7 JEP field semantics;
• clarified that JAC edges do not create authorization or termination cascade;
• changed IANA language to request no action.

References Normative References