What we can actually prove.

Every scan is tied to the ruleset version that judged it at the moment of decision, not attached afterward. Built and live. Not yet exposed as a public unauthenticated endpoint, only viewable inside an account.

A Sentinel reviewer's own read of a flag is sealed before the AI's reasoning is shown to them, both timestamps stored. Built and live. Requires a Sentinel-plan account to demonstrate, no public endpoint yet.

Boundary authorization records extend to API keys and agent credentials, authority granted before the action rather than justified after. Built and live. Account-gated, not yet public.

Live, working both directions with an external peer chain right now. No account needed, run it yourself.

/api/witness/tip

A record-count checkpoint for Red Flag's own public chain is sealed daily, before any export could reference it. Built off the existing hash chain rather than a separate Merkle tree — a sealed count catches tail truncation the same way an inclusion proof would, without needing a tree structure. No account needed, run it yourself.

/api/complete/root

Given a hash, returns either where it's present, or the two real adjacent chain entries that bracket where it would sort if it existed — proof by adjacency on the existing linear chain, not a Merkle tree. Try a value that isn't there.

/api/complete/prove?value={value}

A sample of a customer's own audit entries is sealed before it's used for anything, so a flattering sample can't be picked after the fact. Built and live, account-gated by nature — a sample needs a real account's real data, so there's no honest way to demonstrate it without one.

The scanner's core scoring has no model call and no randomness, so the same input under the same ruleset always produces the same output. Submit content, get a sealed ticket back; resubmit the exact same input to /api/replay/verify later and the ticket must match. Ruleset fingerprint at /api/replay/fingerprint.

/api/replay/challenge

Proving the chain only ever grew (nothing was reordered or rewritten in the middle) needs a formal cryptographic consistency proof between two chain states. Not built. Reports NOT SUPPORTED rather than overclaiming — kept separate from external_anchoring below, since they answer different questions.

Proves the time itself was fixed somewhere Red Flag doesn't control, answering a different question than consistency_proof above: a chain can be perfectly append-only and still have been built last week. Anchored via RFC 3161, a third-party timestamp authority — a different external mechanism than a peer using OpenTimestamps into Bitcoin, same underlying claim. The spec should name the mechanism rather than mandate one.

/api/anchor-status