Evidence and Attestation Lifecycle

Draft 0.1 — 2 August 2026
Cryptographic verification can establish authorship, integrity, and status. It does not automatically prove that a claim is true, complete, causal, current, or made by an independent authority.

Objective

ANUKA needs a trustworthy chain from real-world or system events to human-readable passports and machine-verifiable claims.

The governing rule is:

Never publish a confidence label stronger than the evidence lifecycle that produced it.

The lifecycle is:

source → capture → normalize → claim → evidence package → review → attestation or credential → status → presentation → correction, dispute, revocation, or supersession

Distinct concepts

Source event

An event emitted or observed by a source system.

Examples:

Stripe payment succeeded;
GitHub pull request merged;
feature flag enabled;
experiment exposure assigned;
support ticket resolved;
deployment completed;
participant approved publication.

Observation

A record that a source event or condition was observed at a particular time by a particular collector.

Claim

A statement about a subject.

Examples:

monthly recurring revenue increased;
a participant completed a contribution;
a company controls a domain;
an experiment improved activation;
a credential is currently active.

A claim can be true, false, incomplete, disputed, or conditional.

Evidence

Information offered to support or challenge a claim.

Attestation

A structured, signed claim by an identifiable attester.

Verifiable credential

A set of claims secured and represented according to a declared credential standard, typically involving issuer, holder, subject, verifier, proof, and status concepts.

Verification

Checking declared properties such as signature, issuer, schema, source, method, status, time, authorization, and evidence policy.

Validation

Evaluating whether data satisfies a schema, business rule, acceptance criterion, or method.

Verification and validation do not have identical meanings and should not be used interchangeably in product copy.

Evidence sources

ANUKA should classify sources.

S0 — Self-entered

The subject or organization entered the data manually.

Useful for declarations and discovery, but not source-connected verification.

S1 — Connected first-party system

Data was retrieved from a system controlled by the subject or organization through an authorized integration.

Examples: Stripe, GitHub, Supabase, Sentry, CRM, analytics platform.

This proves source provenance under the integration but may not establish independence.

S2 — Counterparty or participant confirmation

Another identified party confirmed an event or relationship.

Examples: customer receipt, contributor acceptance, reviewer sign-off.

S3 — Independent review

A reviewer outside the subject’s direct operating control evaluated evidence under a declared method.

S4 — Qualified or regulated source

A legally or professionally qualified issuer, auditor, registry, authority, or testing body issued the claim within its authorized scope.

Source classes are contextual; S4 is not required for ordinary product experimentation.

Capture

Every connector should document:

source system;
authentication method;
API version;
account and environment;
permissions granted;
fields collected;
event timestamp and ingestion timestamp;
pagination and completeness assumptions;
webhook or polling behavior;
retry and deduplication method;
deletion and retention behavior;
known limitations.

Source authenticity

Depending on the source, ANUKA may verify:

webhook signatures;
API token ownership;
OAuth grant and scopes;
domain challenge;
repository control;
cryptographic signature;
registry query;
authorized human approval.

A valid webhook signature proves that the message was signed under the source’s mechanism. It does not prove that the source data was not configured, manipulated, refunded, or later corrected.

Canonical events

ANUKA should convert source-specific payloads into versioned canonical events while retaining the original source reference.

Example:

{
  "eventVersion": "0.1",
  "eventId": "anuka:event:01J...",
  "eventType": "commerce.payment.succeeded",
  "subject": "anuka:product:01J...",
  "source": {
    "provider": "stripe",
    "accountRef": "acct_hash",
    "sourceEventId": "evt_...",
    "apiVersion": "declared-version"
  },
  "occurredAt": "2026-08-02T00:00:00Z",
  "ingestedAt": "2026-08-02T00:00:02Z",
  "integrity": {
    "webhookVerified": true,
    "payloadHash": "sha256:..."
  },
  "privacyClass": "business-evidence"
}

Sensitive source payloads should not be copied into public ledgers or public attestations.

Normalization

Normalization must preserve:

original units;
currency and conversion method;
time zone;
cohort and filter definitions;
source and transformation version;
missing or excluded records;
refund, cancellation, reversal, and deletion semantics.

Transformations must be reproducible or sufficiently documented for review.

Claim specification

Before issuing a claim, define:

subject;
predicate or claim type;
value;
time period;
source set;
method;
baseline;
assumptions;
confidence;
issuer or attester;
intended audience and purpose;
expiration or review date;
status mechanism;
dispute mechanism.

Metric claims

A metric claim needs more than a number.

Required fields include:

metric name and version;
numerator and denominator;
aggregation method;
inclusion and exclusion rules;
cohort;
time window;
source systems;
freshness;
absolute value, change, or trend;
statistical or causal limitations;
privacy threshold;
verification state.

Retention improved 8% is ambiguous without specifying relative or absolute change, cohort, period, and method.

Experiment claims

A claim that an intervention affected a metric should include:

hypothesis;
intervention;
variants;
allocation method;
eligibility population;
primary metric;
guardrail metrics;
duration;
sample size;
analysis method;
stopping rule;
exclusions;
confidence or uncertainty;
implementation incidents;
reviewer;
whether the result establishes association or supports causation.

ANUKA must not convert every before-and-after change into a causal claim.

Evidence package

An evidence package is a versioned bundle used by a reviewer or attester.

It may contain:

claim specification;
canonical events or aggregate query references;
transformation manifest;
source hashes;
access-controlled raw evidence locations;
reviewer instructions;
conflicts of interest;
privacy and publication policy;
correction and retention policy.

Evidence packages should be content-addressable where practical.

Review

Reviews may be:

automated schema validation;
deterministic source verification;
statistical review;
product-owner acceptance;
peer review;
independent audit;
qualified professional review.

The interface must state which kind occurred.

A reviewer record should include:

reviewer identity and authority;
method and version;
evidence accessed;
result;
limitations;
conflicts;
timestamp;
signature or audit record.

Attestation issuance

An attestation should contain only the minimum information needed for its purpose.

Suggested fields:

{
  "schemaVersion": "0.1",
  "claimType": "anuka.metric-observation",
  "subject": "anuka:product:01J...",
  "issuer": "anuka:attester:01J...",
  "statement": {
    "metric": "activation-rate",
    "period": "2026-07",
    "changeAbsolutePercentagePoints": 3.2
  },
  "evidenceDigest": "sha256:...",
  "method": "anuka:method:activation-v1",
  "issuedAt": "2026-08-02T00:00:00Z",
  "validUntil": "2026-11-02T00:00:00Z",
  "status": "active",
  "visibility": "permissioned"
}

This is an ANUKA draft envelope, not an EAS or W3C schema.

EAS integration

Ethereum Attestation Service may be used as an implementation layer for structured onchain or offchain attestations.

Potential uses:

schema registration;
signed contribution attestations;
references between attestations;
revocable status;
timestamped public anchors;
tokenless protocol integration.

ANUKA should prefer offchain signed attestations or onchain hashes for sensitive or high-volume data unless a public onchain record provides a clear benefit.

EAS boundary

EAS verifies the structure, signer, chain state, and related protocol properties. The credibility of the claim still depends on the attester, evidence, and method.

W3C credential integration

W3C Verifiable Credentials Data Model v2.0 can represent portable claims issued to or about people, companies, products, and agents.

Data Integrity 1.0 provides mechanisms for authenticity and integrity proofs. Bitstring Status List v1.0 can represent status such as revocation or suspension for compatible credentials.

ANUKA should not require all internal events to become verifiable credentials. Credentials are for portable claims; event logs and source data may remain ordinary signed records.

Onchain versus offchain

Onchain is useful when

public timestamping matters;
multiple independent parties need a shared status;
a public schema or revocation event benefits from durable discovery;
the record contains no sensitive or unnecessary personal data;
cost and chain dependency are acceptable.

Offchain is preferable when

data is sensitive;
high volume is expected;
correction and deletion obligations matter;
disclosure must be selective;
source evidence should remain permissioned;
chain fees or availability are undesirable.

Hybrid pattern

Store evidence privately, issue a signed offchain credential or attestation, and optionally anchor a digest or status reference onchain.

Status lifecycle

Claims and credentials may transition through:

draft;
issued;
active;
suspended;
expired;
revoked;
disputed;
corrected;
superseded;
archived.

Status semantics must be explicit.

Revocation

The issuer declares that a credential should no longer be accepted. Revocation should not be used merely because a claim became old if expiry or supersession is more accurate.

Suspension

Temporary non-acceptance pending review, renewal, or investigation.

Expiry

The credential is no longer current after a declared time.

Supersession

A newer claim or credential replaces the earlier one while preserving history.

Correction

A new record fixes or contextualizes an error. Material corrections should link to the previous record.

Dispute

A subject or relying party challenges accuracy, attribution, method, or interpretation.

Revocation and status privacy

Status checks can become tracking mechanisms if a unique verifier request reveals where and when a credential is used.

ANUKA should prefer privacy-preserving status mechanisms and avoid issuer callbacks that expose every presentation when not necessary.

Bitstring Status List v1.0 is a candidate mechanism because it publishes compact status information without requiring one unique online check per credential presentation.

Time and freshness

Every evidence object should distinguish:

event time;
ingestion time;
issue time;
verification time;
valid-from;
valid-until;
last source synchronization;
last methodology review.

Time sources, clock assumptions, and delayed events should be documented for high-impact claims.

Evidence retention

Retention depends on purpose and data class.

raw source payloads: minimum operational period;
normalized events: according to product need and agreement;
financial records: applicable accounting and tax requirements;
credential evidence: sufficient for verification and dispute;
public attestations: designed to avoid sensitive content before publication;
revoked or corrected claims: retain status relationship without unnecessarily retaining raw personal data.

Data minimization

Evidence systems should avoid:

public customer identifiers;
exact visitor locations;
full URLs with personal data;
private repository content in public hashes without threat analysis;
employee-level performance data in public records;
authentication secrets;
unnecessary legal identity fields;
raw financial transactions when an aggregate claim is enough.

Hashes are not anonymization if the underlying input can be guessed or correlated.

Independence and conflicts

Every attestation should disclose material relationships when independence matters.

Examples:

subject self-attestation;
ANUKA service attesting to data it processed;
resident company attesting to its contributor;
paid independent reviewer;
affiliate or investor attestation;
regulator or accredited body.

The UI must not present affiliated verification as independent verification.

Trust policy

Verification requires a trust policy defining:

acceptable issuers;
acceptable schemas;
signature and cryptosuite requirements;
source classes;
freshness;
status checks;
evidence thresholds;
jurisdiction or role requirements;
conflict rules;
fallback behavior.

Different relying parties may use different policies on the same credential.

Failure behavior

When verification fails, the system should distinguish:

malformed data;
unknown schema;
invalid signature;
unauthorized issuer;
expired credential;
revoked or suspended status;
unavailable status source;
missing evidence;
stale source data;
disputed claim;
policy mismatch.

Do not reduce every failure to not verified.

Auditability

High-impact claim generation should preserve:

code and method version;
source connector version;
query or transformation manifest;
reviewer decision;
credential or attestation payload;
status changes;
publication history;
access logs where appropriate.

Reproducibility may be exact, approximate, or impossible depending on changing source data. The level must be stated.

Prohibited evidence patterns

ANUKA must not:

call a signature proof of truth;
publish sensitive raw data onchain;
create causal claims from uncontrolled before-and-after changes;
let a subject silently rewrite a relied-upon metric history;
call automated validation an independent audit;
omit refunds, reversals, failed events, or excluded cohorts when material;
use hashes as a substitute for data minimization;
issue permanent credentials for rapidly changing claims without expiry;
conceal reviewer conflicts;
treat unavailable status as active without a declared policy.

MVP acceptance criteria

The first evidence release is ready when:

source events retain provenance and connector version;
canonical events are versioned and deduplicated;
claims declare method, period, source, issuer, status, and limitations;
raw evidence and public attestations are separate;
correction, dispute, revocation, suspension, expiry, and supersession are supported;
every public metric identifies its source class;
onchain publication is opt-in and excludes sensitive data;
EAS integration, if enabled, is presented as an attestation transport rather than a truth oracle;
credential status checks fail safely;
evidence packages can be exported for authorized review.

Sources

Verification record

Sources opened and checked: 2 August 2026
W3C Recommendation baseline: 15 May 2025
Evidence architecture status: Draft
Cryptography, privacy, chain selection, and independent-audit claims require specialist review: Yes