Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Native library reference. Extended CLI examples use jacs-compat. This source reference can include unreleased changes; see the package guide for installation and MCP profiles for available tools.

Creating and Using Agreements

Agreement v2 is the native compatibility agreement model. It is a standalone jacsType: "agreement" document that captures terms, parties, transcript references, signature policy, consent signatures, and version lineage.

Use Agreement v2 to inspect existing native agreement signatures and claimed status. The report always keeps valid=false and policyAccepted=false: party proofs do not authenticate the complete role, quorum, lineage or finalization policy. New portable consent uses Agreement v3.

Agreement v2 Model

The JACS header still owns document identity, versioning, authorship signatures, hashes, registration, files, and visibility. The agreement body owns consent:

  • title, description, terms, termsFormat
  • effectiveFrom, expiresAt
  • parties
  • signaturePolicy
  • agreementSignatures
  • transcript
  • allPreviousVersions
  • links
  • controllers, owners

jacsAgreementHash is the consent hash. It changes when terms, parties, signature policy, or effective/expiry dates change. Transcript appends do not change it; signers bind the transcript state with signedTranscriptHash when transcript entries exist.

Roles

RoleMeaning
signerConsents to the terms and counts toward partyQuorum
witnessAttests to process, time, or identity and counts toward witnessRequired
notaryProvides notarial attestation; HAI uses this role and it counts toward notaryRequired
observerListed participant that does not sign

Minimal Input

{
  "title": "Refund approval",
  "description": "Agent A and Agent B agree on a bounded refund.",
  "terms": "Agent B may issue a refund up to $25 for order 123.",
  "termsFormat": "text/plain",
  "status": "proposed",
  "parties": [
    { "agentId": "00000000-0000-4000-8000-000000000001", "agentType": "ai", "role": "signer" },
    { "agentId": "00000000-0000-4000-8000-000000000002", "agentType": "human", "role": "signer" },
    { "agentId": "00000000-0000-4000-8000-000000000003", "agentType": "ai", "role": "notary" }
  ],
  "signaturePolicy": {
    "partyQuorum": "all",
    "witnessRequired": 0,
    "notaryRequired": 1,
    "minimumStrength": "classical"
  },
  "controllers": [
    "00000000-0000-4000-8000-000000000001",
    "00000000-0000-4000-8000-000000000002",
    "00000000-0000-4000-8000-000000000003"
  ]
}

Rust Core API

Rust core is the source of truth for Agreement v2 behavior. Binding surfaces call into the same helpers.

#![allow(unused)]
fn main() {
use jacs::agreements::v2::{
    create,
    sign,
    verify,
    AgreementV2Role,
    CreateAgreementV2,
};

let agreement = create(&agent, input)?;
let signed = sign(&agent, &agreement.raw, AgreementV2Role::Signer)?;
let report = verify(&agent, &signed.raw)?;

assert!(report.mathematical_checks_valid);
assert!(!report.valid);
assert!(!report.policy_accepted);
}

Use mutations for successor versions instead of editing JSON by hand. The helpers maintain jacsAgreementHash, jacsPreviousVersion, allPreviousVersions, status, and signature invalidation.

CLI

jacs-compat agreement-v2 create --input agreement-input.json > agreement.json
jacs-compat agreement-v2 sign --agreement agreement.json --role signer > signed.json
jacs-compat agreement-v2 verify --agreement signed.json

Branch handling is also in core and exposed through the CLI:

jacs-compat agreement-v2 detect-conflict --base base.json --left left.json --right right.json
jacs-compat agreement-v2 merge-transcript --base base.json --left left.json --right right.json
jacs-compat agreement-v2 resolve-conflict --base base.json --previous left.json --side-branch right.json --mutation resolution.json

Transcript-only branches can auto-merge. Terms conflicts require an explicit successor mutation.

Legacy Sidecar Agreements

Legacy v1; new work should use Agreement v2. See Migrating from v1 agreements.

The older jacsAgreement field on arbitrary signed documents remains available for simple countersignature workflows:

jacs-compat document create-agreement -f ./document.json -i agent1-uuid,agent2-uuid
jacs-compat document sign-agreement -f ./document-with-agreement.json
jacs-compat document check-agreement -f ./document-with-agreement.json

Use the legacy sidecar only when you need "these keys signed this existing payload (without authenticated consent policy)." Use Agreement v2 when you need standalone terms, lifecycle, transcript evidence, notary signatures, branch handling, or portable SDK parity.

Exporting as a Verifiable Credential

With the agreements feature, SimpleAgent::export_agreement_v2_as_vc(agreement_json) projects an Agreement-v2 document into a VC 2.0 credential with an ecdsa-jcs-2019 Data Integrity proof (ES256 compatibility key, Multikey verification method). It requires the agreement-vc binding scope — content scopes are never auto-issued — and never mutates the native agreement. See the Agreement v2 Developer Guide for the full flow.

See Also