VeritasChain Standards Organization

Japan standards@veritaschain.org https://veritaschain.org

Security Supply Chain Integrity, Transparency, and Trust SCITT AI safety refusal events transparency service audit trail claim set CDDL This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. About This Document The latest version of this document, along with implementation resources and examples, can be found at <https://github.com/veritaschain/cap-spec>. Discussion of this document takes place on the SCITT Working Group mailing list (scitt@ietf.org).

Introduction AI systems capable of generating content increasingly implement safety mechanisms to refuse requests deemed harmful, illegal, or policy-violating. However, these refusal decisions typically leave no verifiable audit trail. When a system refuses to generate content, the event vanishes--there is no receipt, no log entry accessible to external parties, and no mechanism for third-party verification. This document defines a claim set for recording such refusal events. The claim set specifies:

• The semantic meaning of each claim
• Correlation rules linking attempts to outcomes
• A completeness invariant for audit trail integrity
• Privacy-preserving approaches using cryptographic hashes

The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This document does not mandate a specific serialization; implementations may use CBOR, JSON, or other formats as appropriate for their deployment context.

Motivation The January 2026 Grok incident demonstrated the need for verifiable refusal records. The AI system generated millions of harmful images while the provider claimed moderation systems were functioning. External parties had no mechanism to verify whether refusals actually occurred or whether claimed safeguards were enforced. This creates several problems:

• Regulators cannot independently verify that AI providers enforce stated policies
• Providers cannot prove to external auditors that specific requests were refused
• Third parties investigating incidents have no way to establish refusal without trusting provider claims

SCITT provides the infrastructure--Signed Statements, Transparency Services, and Receipts--to address this gap. This document defines the claim semantics for AI refusal events that can be carried within that infrastructure.

Scope This document defines:

• A claim set for ATTEMPT and Outcome events
• Semantic definitions for each claim
• A completeness invariant for correlation
• A CDDL grammar for CBOR representation
• Integration guidance for SCITT Transparency Services

This document does NOT define:

• Content moderation policies
• Classification algorithms or risk scoring
• Mandatory serialization formats
• Transparency Service behavior beyond standard SCITT
• Regulatory compliance requirements

This specification is an application profile for SCITT, defining domain-specific claim semantics. It does not extend or modify SCITT architecture.

Limitations This specification provides auditability of refusal decisions that are logged, not cryptographic proof that no unlogged generation occurred. An AI system that bypasses logging entirely cannot be detected by this mechanism alone. Transparency Services do not enforce the completeness invariant defined in this document; such checks are performed by verifiers at the application level using the claim semantics defined herein.

Relationship to Other Work This document defines claim semantics for the refusal of a content generation request. It is scoped to what an AI system declined to produce and to the correlation between a request and its outcome. It does not define transition semantics for agentic systems; addresses refused agent-system transitions and replay resistance, and is complementary to the work here. Deployments concerned with both surfaces may record claim sets under both specifications; this document does not define a mapping between them. This claim set specifies the refusal-event mechanism of the Content / Creative AI Profile (CAP) within the Verifiable AI Provenance Framework , an architectural framework for making processing records tamper-evident, completeness-checkable, and attributable after the fact. The framework does not warrant the correctness, fairness, or safety of the underlying AI decisions; it concerns only the integrity, completeness at anchor granularity, and attributability of their records. The same limit applies to this document: recording a refusal establishes that a refusal was claimed and when, not that the refusal was correct. The Evidence Pack format referenced in is defined by CAP-SRP , a companion specification for content and creative AI applications.

Changes from draft-kamimura-scitt-refusal-events-03 No claim names, CDDL definitions, correlation rules, or completeness invariant semantics were changed; -03 claim sets remain valid under this revision.

• Replaced the statement that creating ATTEMPT before evaluation "prevents" selective logging with a description of what it makes detectable, consistent with .
• Distinguished the ATTEMPT/Outcome invariant from batch completeness after anchoring.
• Reworded the Omission Attacks, threat model, registration timing and Regulated Deployment text so that it claims neither prevention, guarantees, nor regulatory compliance.
• Stated that this claim set is the refusal-event mechanism of CAP within VAP.
• Added an Implementation Status section ().

Changes from draft-kamimura-scitt-refusal-events-02 The SCITT architecture was published as in June 2026. References to the superseded Internet-Draft have been replaced throughout, which removes a normative reference to a work in progress. No claim names, CDDL definitions, correlation rules, or completeness invariant semantics were changed; -02 claim sets remain valid under this revision. This revision also adds , updates the SCITT Reference APIs citation to its current revision, and revises one non-normative deployment suggestion in .

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.

Terminology This document uses terminology from . The following terms are specific to this specification:

Generation Request

A request submitted to an AI system to produce content.

Refusal Event

A decision by an AI system to decline a generation request.

ATTEMPT

A claim set recording that a generation request was received.

DENY

A claim set recording that a generation request was refused. References the corresponding ATTEMPT.

GENERATE

A claim set recording successful content generation. References the corresponding ATTEMPT.

ERROR

A claim set recording system failure during processing. References the corresponding ATTEMPT.

Outcome

Any of DENY, GENERATE, or ERROR.

Completeness Invariant

The property that every logged ATTEMPT has exactly one corresponding Outcome.

Verifiable Refusal Record

An ATTEMPT claim set, a DENY claim set, and Receipts proving their registration with a Transparency Service.

Mapping to SCITT This specification maps directly to SCITT primitives:

This Document	SCITT Primitive
ATTEMPT claim set	Signed Statement payload
Outcome claim set	Signed Statement payload
AI System	Issuer
Inclusion proof	Receipt

Claim Set Definition This section defines the claims for refusal events. Claims are specified by their semantic meaning; encoding is deployment-specific. provides a CDDL grammar for CBOR representation.

Common Claims The following claims appear in all event types:

event-type (REQUIRED)

One of: "ATTEMPT", "DENY", "GENERATE", "ERROR". Identifies the event category.

event-id (REQUIRED)

Unique identifier for this event. UUIDv7 is RECOMMENDED for temporal ordering.

timestamp (REQUIRED)

Time of event occurrence. In CBOR, MUST be either tag 0 (RFC 3339 date-time string) or tag 1 (epoch-based integer/float). Untagged integers representing Unix epoch seconds are also permitted.

issuer (REQUIRED)

Identifier of the AI system that created this event. SHOULD be a URI.

ATTEMPT Claims An ATTEMPT records receipt of a generation request. It MUST be created before any safety evaluation begins.

prompt-hash (REQUIRED)

Cryptographic hash of the prompt content. MUST use SHA-256 or stronger. The original prompt MUST NOT be stored.

input-type (REQUIRED)

Type of input: "text", "image", "text+image", "audio", "video", or "multimodal".

reference-input-hashes (OPTIONAL)

Array of hashes for non-text inputs (images, audio, etc.).

session-id (OPTIONAL)

Session identifier for correlation across requests.

actor-hash (OPTIONAL)

Pseudonymized hash of the requesting entity.

model-id (OPTIONAL)

Identifier of the AI model processing the request.

policy-id (OPTIONAL)

Identifier of the content policy being applied.

The requirement to create ATTEMPT before safety evaluation makes selective logging, where only "safe" requests are recorded, detectable among registered ATTEMPTs: an ATTEMPT without an Outcome is visible to a verifier. It does not reveal requests for which no ATTEMPT was registered ().

DENY Claims A DENY records refusal of a generation request.

attempt-id (REQUIRED)

The event-id of the corresponding ATTEMPT. This establishes the correlation required by the completeness invariant.

risk-category (OPTIONAL)

Category of policy violation. Values are deployment-specific; provides a non-normative taxonomy.

risk-score (OPTIONAL)

Confidence score, 0.0 to 1.0.

refusal-reason (OPTIONAL)

Human-readable reason. SHOULD NOT contain prompt content.

human-override (OPTIONAL)

Boolean indicating human reviewer involvement.

GENERATE Claims A GENERATE records successful content generation.

attempt-id (REQUIRED)

The event-id of the corresponding ATTEMPT.

output-hash (OPTIONAL)

Hash of the generated content, for correlation with downstream provenance (e.g., C2PA manifests).

ERROR Claims An ERROR records system failure, not a policy decision.

attempt-id (REQUIRED)

The event-id of the corresponding ATTEMPT.

error-code (OPTIONAL)

Machine-readable error identifier.

error-message (OPTIONAL)

Human-readable error description.

ERROR does not indicate policy enforcement. A high ERROR rate may indicate operational issues or adversarial inputs.

Completeness Invariant The completeness invariant is the core integrity property: For every ATTEMPT with event-id A that is registered with a Transparency Service, there MUST exist exactly one Outcome (DENY, GENERATE, or ERROR) with attempt-id equal to A. Formally: where each Outcome references exactly one ATTEMPT, and no ATTEMPT is referenced by multiple Outcomes. Violations indicate:

• ATTEMPT without Outcome: incomplete logging or in-progress request
• Outcome without ATTEMPT: fabricated outcome or logging failure
• Multiple Outcomes per ATTEMPT: data integrity failure

Verifiers SHOULD check this invariant when auditing event streams. Transparency Services do not enforce this invariant; it is an application-level semantic constraint. This invariant concerns the correspondence between registered ATTEMPTs and Outcomes. It is distinct from batch completeness after anchoring in the VAP framework : removing an ATTEMPT together with its Outcome preserves the invariant. Detecting such a removal requires a commitment to the set of registered statements, such as the Transparency Service's log or an anchored batch with a bound event count.

Timing Requirements To maintain audit trail integrity:

• ATTEMPT MUST be created before safety evaluation begins
• Outcome SHOULD be created promptly after decision
• Outcome timestamp MUST be greater than or equal to ATTEMPT timestamp

Some scenarios require delayed outcomes (human review, system recovery). Implementations SHOULD document expected latency bounds.

CDDL Definition This section provides a CDDL grammar for CBOR-based representation of the claim set. This grammar is RECOMMENDED for implementations using CBOR encoding within SCITT Signed Statements. Implementations using other encodings (e.g., JSON) SHOULD maintain semantic equivalence with this definition. any ; extension point } input-type-value = "text" / "image" / "text+image" / "audio" / "video" / "multimodal" ; Outcome events outcome-event = deny-event / generate-event / error-event deny-event = { common-claims, attempt-id: uuid, ? risk-category: tstr, ? risk-score: float16 .le 1.0, ? refusal-reason: tstr, ? human-override: bool, * tstr => any } generate-event = { common-claims, attempt-id: uuid, ? output-hash: hash-value, * tstr => any } error-event = { common-claims, attempt-id: uuid, ? error-code: tstr, ? error-message: tstr, * tstr => any } ; Supporting types uuid = bstr .size 16 / tstr ; binary or string representation hash-value = bstr / tstr ; raw bytes or prefixed string time = #6.0(tstr) / #6.1(number) / uint ; tag 0 (date-time string), ; tag 1 (epoch), or raw uint ]]> Notes on the CDDL definition:

• Extension points (* tstr => any) allow deployment-specific claims without breaking interoperability
• UUID may be binary (16 bytes) or string (RFC 9562 format)
• Hash values may be raw bytes or prefixed strings (e.g., "sha256:...")
• Timestamps support CBOR tag 0 (RFC 3339 date-time string), tag 1 (epoch-based number), or untagged epoch seconds

The claim names defined in this specification (e.g., "event-type", "prompt-hash") represent semantic labels. Implementations MAY use alternative key representations (such as short integer labels for CBOR efficiency) provided the semantic meaning is preserved and documented.

SCITT Integration This section describes how refusal event claim sets integrate with SCITT infrastructure.

Encoding as Signed Statements A refusal event claim set is carried as the payload of a SCITT Signed Statement:

• The claim set is serialized (CBOR RECOMMENDED)
• The serialized bytes become the COSE_Sign1 payload
• The Issuer is the AI system's signing identity
• Content-Type SHOULD indicate the claim set format

For CBOR-encoded claim sets, the Content-Type "application/cbor" or a more specific media type MAY be used.

Registration After creating a Signed Statement, the Issuer SHOULD register it with a SCITT Transparency Service via SCRAPI . The Transparency Service returns a Receipt proving inclusion. Issuers SHOULD store Receipts for future verification requests. Registration timing affects audit trail integrity:

• Prompt registration provides stronger temporal assurance
• Batched registration may be acceptable for non-time-critical audits

Verification A Verifiable Refusal Record consists of:

1. ATTEMPT Signed Statement and Receipt
2. DENY Signed Statement and Receipt
3. Verification that attempt-id in DENY equals event-id in ATTEMPT

Verifiers confirm:

• Both Receipts are valid for the Transparency Service
• Both Signed Statements have valid Issuer signatures
• The attempt-id correlation is correct
• Timestamps are consistent (Outcome >= ATTEMPT)

This demonstrates that a refusal was logged. It does not prove that no unlogged generation occurred.

Registration Policy Considerations A Transparency Service MAY apply a Registration Policy that validates:

• Required claims are present
• Timestamp is within acceptable bounds
• Issuer is authorized (if restricted)

Transparency Services SHOULD NOT attempt to enforce the completeness invariant; this is an application-level verification performed by auditors.

Implementation Status Note to the RFC Editor: please remove this section before publication. This section records the status of known implementations at the time of posting, following . The listing of any individual implementation here does not imply endorsement by the IETF, and the information presented here has not been verified by the IETF. Other implementations may exist.

• There are no known external implementations of these claim sets or of CAP-SRP.
• VSO publishes a first-party proof-of-concept reference implementation of CAP Safe Refusal Provenance (https://github.com/veritaschain/cap-safe-refusal-provenance). It has not been assessed against the claim sets of this document.
• No Evidence Pack containing these claim sets has been accepted in any regulatory, judicial, or audit proceeding.

IANA Considerations This document has no IANA actions at this time. Future revisions may request:

• Registration of a media type for refusal event claim sets
• Establishment of a registry for event-type values
• Establishment of a registry for risk-category values

The working group should consider whether standardized registries would benefit interoperability, or whether deployment-specific vocabularies are sufficient.

Security Considerations

Threat Model This specification assumes:

• The AI system (Issuer) is partially trusted: expected to log events but may have bugs or be compromised
• The Transparency Service is partially trusted: expected to operate an append-only log but may be compromised
• Verifiers are trusted to perform completeness checks

This specification does NOT protect against:

• An AI system that bypasses logging entirely
• Collusion between Issuer and Transparency Service

Omission Attacks An adversary controlling the AI system might omit events to hide policy violations. The completeness invariant provides detection for logged events: auditors can identify ATTEMPTs without Outcomes. However, if an ATTEMPT is never logged, this specification cannot detect the omission. Addressing such omissions requires external mechanisms (for example, trusted execution or attestation ) outside this specification's scope, and those mechanisms do not by themselves establish that every request was logged.

Log Equivocation A malicious Transparency Service might present different views to different parties. Mitigations include:

• Gossiping of Signed Tree Heads between verifiers
• Registration with multiple Transparency Services
• External anchoring to public ledgers

Replay Attacks Replay of old events is mitigated by:

• UUIDv7 temporal ordering
• Timestamp verification against registration time
• Receipt binding to specific log position

Dictionary Attacks on Hashes An adversary with a dictionary of prompts could attempt to identify which prompt was used by hash comparison. Mitigations include:

• Access controls on event queries
• Rate limiting
• Time-limited retention

Privacy Considerations

Harmful Content Refusal events may be triggered by harmful content. To prevent the audit log from becoming a repository of harmful content:

• prompt-hash stores only a hash, not the original
• refusal-reason SHOULD NOT quote prompt content
• Reference images are stored as hashes only

Actor Privacy actor-hash provides pseudonymization. Implementations SHOULD:

• Use pseudonymous identifiers by default
• Maintain separate access-controlled identity mappings
• Support crypto-shredding for data deletion

Correlation Risks Event metadata may enable correlation attacks:

• Timestamps reveal activity patterns
• session-id links requests
• model-id reveals system usage

Implementations SHOULD apply appropriate access controls.

References Normative References Informative References VeritasChain Standards Organization https://github.com/veritaschain/cap-spec

Risk Category Taxonomy (Non-Normative) This appendix provides an example taxonomy for risk-category values. This taxonomy is non-normative; deployments MAY use different values appropriate to their context.

Category	Description
CSAM_RISK	Child sexual abuse material
NCII_RISK	Non-consensual intimate imagery
MINOR_SEXUALIZATION	Sexualization of minors
REAL_PERSON_DEEPFAKE	Unauthorized realistic depiction
VIOLENCE_EXTREME	Graphic violence
HATE_CONTENT	Discriminatory content
TERRORIST_CONTENT	Terrorism-related material
SELF_HARM_PROMOTION	Self-harm encouragement
COPYRIGHT_VIOLATION	Clear IP infringement
COPYRIGHT_STYLE_MIMICRY	Artist style imitation
OTHER	Other policy violations

A future revision may define an IANA registry for risk categories if interoperability requires standardized values.

Deployment Considerations (Non-Normative) This appendix provides guidance for deployments with varying assurance requirements. These are not conformance tiers; all deployments MUST satisfy the normative requirements in .

Basic Deployment Suitable for voluntary transparency:

• Log ATTEMPT and Outcome events locally
• Register with Transparency Service periodically (daily)
• Retain events for 6+ months
• Provide Evidence Packs on request

Regulated Deployment For deployments subject to regulatory recordkeeping obligations (for example, logging obligations under the EU AI Act). Following these practices does not by itself establish compliance with any regulation:

• Register events promptly (within minutes)
• Implement continuous completeness monitoring
• Retain events for 2+ years
• Provide programmatic audit API
• Document latency bounds and retention policies

High-Assurance Deployment Suitable for maximum accountability:

• Register events in real-time (within seconds)
• Use HSM for signing keys
• Register with multiple Transparency Services
• Anchor to multiple independent targets (e.g., additional RFC 3161 time-stamp authorities)
• Retain events for 5+ years
• Support 24-hour incident response

JSON Representation Example (Non-Normative) This appendix shows equivalent JSON representations of the claim sets defined in . These examples are for illustration; the normative definition is the CDDL in .

ATTEMPT Example

DENY Example

Evidence Pack Format (Non-Normative) An Evidence Pack is a self-contained collection of events suitable for regulatory submission or third-party audit. This format is deployment-specific and not required for conformance. A typical Evidence Pack contains:

• Manifest with metadata and checksums
• Serialized events (CBOR or JSON Lines)
• Receipts from Transparency Services
• Completeness verification results
• Public keys for signature verification

The CAP-SRP specification defines a detailed Evidence Pack format for content AI applications.

Acknowledgements The authors thank the SCITT Working Group for feedback on earlier revisions, particularly regarding SCITT charter scope and the distinction between claim semantics and payload formats. This work builds upon transparency log concepts from Certificate Transparency and the SCITT architecture.