Identify & expand
ShippingContent identity from bytes, accepted interpretations, and recursive assets under explicit budgets.
How it works
The homepage says a decision depends on what happens next. This page is the mechanism behind that: what content can do, who is about to consume it, how it arrived, and how far each of those is actually built.
The stages
Content identity from bytes, accepted interpretations, and recursive assets under explicit budgets.
Observations with derivation, completeness and traceability — how strongly a thing is known, not just that it was seen.
What the content can do, normalised across carriers. A canonical contract with mapping identity and coverage — today bounded and diagnostic, not yet policy authority.
Who or what consumes it, with which privileges, how it arrived, and where it is going.
Whether an absence of findings means anything at all for this content.
One request-specific decision — allow, constrain, review, refuse or transform — over the content-intrinsic graph. The authoritative boundary is being built.
A safer derivative, the residual evidence, and what the transformation preserved or removed.
The same decision applied at the workbench, the CLI, the endpoint or the content boundary.
A PDF launch action, an Office hyperlink, an SVG reference and a hidden model instruction look nothing alike on disk. Normalised as effects, several are the same thing wearing different clothes — which is what lets a control survive the next carrier rotation instead of chasing file extensions.
Something runs — a macro, a script, an embedded interpreter, a launched handler.
The content reaches out: a remote template, a linked resource, a callback, a tracking fetch.
Something leaves — credentials, tokens, form contents, or the file itself.
A person is persuaded to act: a lure, a fake workflow, a copy-and-run instruction.
A model, retriever or agent is steered — hidden instructions, poisoned context, tool-use directives.
Partial The effect vocabulary and its coverage across carriers are still being completed.
Content credentials, watermarks, provider markings, device attestations and trust lists are evidence, mapped through versioned provider-neutral profiles into our own model. They do not become canonical types just because a standard defines them, and binding validity stays separate from whether the issuer is trusted.
Roadmap The internal foundation has landed; there is no general verifier or cross-provider decision plane today. C2PA is a planned first reference profile — not present-tense support.
The same capability lands differently depending on the consumer and its privileges.
Roadmap A single canonical consumer, action and destination contract is being built.
Acquisition context changes the decision without changing a byte.
Roadmap Canonical custody is still distributed across surfaces.
The workbench runs this analysis locally and shows the evidence, the coverage and the gaps for whatever you drop into it.