Provenance-stamped data for auditable AI agents.
When you need to prove what data an agent acted on, every Dynamic Feed datapoint arrives signed and stamped with its source and observed-at time.
The call
A keyless call to /v1/batch. Look past the answer at the envelope: provenance (source, measured_at, license), freshness (state, observed_at) and an Ed25519 signature over the datapoint. That envelope is what you log next to the agent decision.
curl -s -X POST https://dynamicfeed.ai/v1/batch \
-H 'Content-Type: application/json' \
-d '{"calls":[{"tool":"reality_check","args":{"claim":"the latest stable Python is 3.12"}}]}'
# each result carries provenance{source, measured_at, license, age_seconds},
# freshness{state, observed_at}, and signature{alg:"Ed25519", key_id, sig}Sample response
{
"tool": "reality_check",
"data": { "subject": "python", "live_value": "3.14.6", "verdict": "stale_or_wrong" },
"provenance": { "source": "endoflife.date", "measured_at": "2026-06-15T03:28:57Z", "age_seconds": 0 },
"freshness": { "state": "live", "observed_at": "2026-06-15T03:28:57Z" },
"signature": { "alg": "Ed25519", "key_id": "df-ed25519-6ca0de29113b", "sig": "..." }
}Why live data
An agent decision is only as auditable as the inputs behind it. A bare API response cannot answer "what did the model see, from where, and when" after the fact. Dynamic Feed wraps every datapoint in a verifiable envelope: a provenance stamp (the upstream source, the observed-at timestamp and a freshness state) plus an Ed25519 signature you can check offline against our published key. Log the envelope alongside the agent step and you have a tamper-evident record of the reported input. One important boundary: the signature establishes integrity and attribution under the published key, so altered bytes fail verification. It does not independently prove time, truth, accuracy, or safety. You still own the upstream-source judgement; we make the chain of custody checkable.
Use it for
- Log the signed envelope next to each agent decision for after-the-fact audit
- Detect tampering or replay in cached agent inputs by re-verifying the signature
- Cite source and observed-at when an agent answer is challenged
- Build a compliance trail showing which data version drove an automated action
FAQ
Does the signature mean the data is correct?
No. The Ed25519 signature establishes integrity and attribution under the published key, so altered bytes fail verification. It does not independently prove time, truth, accuracy, or safety. The provenance stamp tells you the upstream source and reported observation time so you can judge those yourself.
How do I verify a signature without trusting your server?
Each datapoint includes a signature block with the algorithm and key_id. Fetch our public key from the published JWKS endpoint and verify the canonical bytes offline with any Ed25519 library. There is also an open verifier script so you can confirm a saved envelope long after the call.
What does the provenance stamp contain?
Source name and URL, the observed-at (measured_at) timestamp, a license note, an age_seconds value, and a freshness state. That lets an auditor see exactly where a number came from and how current it was at decision time. No API key is needed to receive it.