Generated from packages/spec/v0.1/profiles/contract-negotiation.md. Edit the source file, not this page.

Contract Negotiation Profile 0.1

Status: implementer draft.

1. Purpose

The contract negotiation profile is the first Agent Revision Markup profile.

The core protocol is broader than contracts. This profile constrains it for the highest-stakes first use case: documents crossing party boundaries where each side must be able to check the record without trusting the other's platform.

2. Profile Identifier

urn:agentrevisionmarkup:profile:contract-negotiation:0.1

Manifests that implement this profile SHOULD include the profile identifier.

3. Vocabulary

This profile uses clause anchors and contract topic vocabularies.

The topic vocabulary mechanism is core. The concrete contract topics are profile data.

Topic references SHOULD be content-hash pinned. A verifier MUST check topic membership against the pinned topic list, not against a mutable URI alone.

4. Decision Kinds

This profile uses the core decision vocabulary:

• propose
• counter
• accept
• reject
• escalate

This profile SHOULD define product semantics for reject before using it as a visible user action. In particular, implementations must decide whether rejecting a proposed action is itself a recorded turn or a local non-event.

5. Mandates

A mandate grants scoped authority to an agent.

Mandate ids MAY appear in signed turns. The private content of a mandate, including the full playbook that produced it, SHOULD NOT be disclosed in the shared record unless both parties intend that disclosure.

This profile RECOMMENDS carrying only:

• mandate id
• party id
• topic or clause scope
• public rationale when needed
• human approval binding for consequential turns

Private playbooks remain outside the document.

6. Visible Artifacts

This profile maps record-defined artifacts to:

• Word comments
• tracked insertions
• tracked deletions
• tracked replacements
• durable anchors, such as content controls

The visible layer is for humans. The record is for tools. A runtime SHOULD preserve both.

7. Human Approval

Consequential agent-authored turns SHOULD use human-approved-agent-draft.

Approval UI MUST show the human:

• the affected clause or anchor
• the exact proposed visible change
• the public rationale
• the approving identity
• the destination or sharing state if a service will be contacted

The approval signature MUST bind to the exact draft shown.

8. Extensions

Common profile extensions include:

• playbook traceability
• review workflow references
• CLM matter references
• document management ids
• internal run ids

Once the extension surface lands, these fields SHOULD be carried as namespaced extensions. They SHOULD NOT be promoted to required profile fields unless independent vendors need the same field with the same semantics.