Specification · Reference model

OConsent Draft Specification

A reference model for machine-readable consent records, point-of-use verification, revocation, and audit events in AI systems.

Draft / Reference Model

Status

This is an evolving reference model. It is designed to be compatible with LLMConsent-style consent records and open AI consent standards, but it should not be represented as a finalized industry standard.

01 / Object

Consent Record

A Consent Record represents a subject's permission for a specific actor to use a specific asset for one or more purposes under defined scope and time constraints.

consent_record.json

{
  "id": "rec_7f3a",
  "subject": "user_123",
  "asset": "conversation_export",
  "purpose": "llm_training",
  "actor": "model_pipeline_7",
  "scope": {
    "allowed_operations": ["train", "evaluate"],
    "excluded_operations": ["resell", "share_external"],
    "geography": ["SG", "US"],
    "retention_days": 365
  },
  "issued_at": "2026-06-28T00:00:00Z",
  "expires_at": "2027-06-28T00:00:00Z",
  "status": "active",
  "proof": {
    "type": "signed_timestamp",
    "hash": "sha256:..."
  }
}

id: Unique consent record identifier.
subject: Person, creator, customer, organization, or data subject granting consent.
asset: Data asset, dataset, file, conversation, memory, embedding, or derived resource.
purpose: Intended use, such as llm_training, personalization, agent_memory, or research.
actor: App, model, agent, pipeline, organization, or processor requesting use.
scope: Constraints on allowed and excluded usage, geography, and retention.
issued_at: Time consent was granted.
expires_at: Time consent expires.
status: active, expired, revoked, or suspended.
proof: Tamper-evident proof metadata. Optional cryptographic anchoring for tamper-evident consent proofs.

02 / Object

Verification Request

A Verification Request asks whether a specific actor can use a specific asset for a specific purpose at a specific point in time.

verification_request.json

{
  "subject": "user_123",
  "asset": "conversation_export",
  "purpose": "llm_training",
  "actor": "model_pipeline_7",
  "requested_at": "2026-06-28T10:20:00Z"
}

subject: The data subject whose consent is being checked.
asset: The asset the actor wants to use.
purpose: The intended use being requested.
actor: The app, model, agent, or pipeline requesting use.
requested_at: Time the check is made.

03 / Object

Verification Response

A Verification Response returns an allow or deny decision, the reason for the decision, the consent record used, and optional audit metadata.

verification_response.json

{
  "allowed": true,
  "decision": "allow",
  "reason": "active_consent_record_found",
  "consent_record_id": "rec_7f3a",
  "checked_at": "2026-06-28T10:20:01Z",
  "audit_event_id": "audit_91ac"
}

allowed: Boolean allow or deny outcome.
decision: allow or deny.
reason: Machine-readable reason code for the decision.
consent_record_id: The record the decision was based on, if any.
checked_at: Time the decision was returned.
audit_event_id: The audit event recording this check, if logged.

04 / Object

Revocation Event

A Revocation Event records that a consent record is no longer valid for future use.

revocation_event.json

{
  "id": "rev_22b9",
  "consent_record_id": "rec_7f3a",
  "subject": "user_123",
  "revoked_at": "2026-07-10T09:00:00Z",
  "reason": "user_requested_revocation"
}

id: Unique revocation event identifier.
consent_record_id: The consent record being revoked.
subject: The subject who revoked the permission.
revoked_at: Time the revocation took effect.
reason: Machine-readable reason for revocation.

05 / Object

Audit Event

An Audit Event records that a consent decision was checked, what decision was returned, and where the decision was enforced.

audit_event.json

{
  "id": "audit_91ac",
  "consent_record_id": "rec_7f3a",
  "actor": "model_pipeline_7",
  "asset": "conversation_export",
  "purpose": "llm_training",
  "decision": "allow",
  "checked_at": "2026-06-28T10:20:01Z",
  "enforcement_point": "fine_tuning_pipeline"
}

id: Unique audit event identifier.
consent_record_id: The record the decision was based on.
actor: The actor that requested use.
asset: The asset involved in the decision.
purpose: The purpose that was checked.
decision: allow or deny.
checked_at: Time the decision was made.
enforcement_point: Where the decision was enforced, such as fine_tuning_pipeline.

06 / Registry

Purpose registry

Purpose names should be stable, machine-readable, and organization-specific where needed. These are common examples.

llm_training: Training a model on the asset.
model_finetuning: Fine-tuning an existing model on the asset.
agent_memory: Storing the asset in an agent's long-term memory.
personalization: Tailoring outputs to the subject.
evaluation: Testing or benchmarking with the asset.
research: Research and analysis.
analytics: Aggregate analytics.
partner_sharing: Sharing the asset with a partner.

07 / Decisions

Decision reason codes

A verification response carries a machine-readable reason code alongside the allow or deny decision.

Allow Deny

08 / Enforcement

Enforcement points

Where a decision is checked and applied. An audit event records the enforcement point.

Compatibility

OConsent is designed to map to LLMConsent-style consent records, but this page describes the OConsent reference model, not the LLMConsent standard itself.

Implement the model.

Use these objects as the contract between the systems that issue, verify, revoke, and audit consent.

Read the developer guide → Explore LLMConsent ↗