This FAQ describes the published 0.1.0 alpha (PyPI and GitHub, 2026-10-01), the foundation for later releases. Pin the version.
How do we detect a record changed later?
The SDK calculates a SHA-256 identity over the canonical record. Changing a field changes that identity. Source-file bytes have a separate digest. A consumer compares the received record or content against the expected digest retained from an earlier, trusted handoff. Calculating a fresh digest from the changed record and accepting that as the new expectation would defeat the check.
RecordStore appends records and linked revisions through its API. Corrections retain earlier versions. Store verification checks internal identities, references and log consistency. These are useful integrity controls, but append-only API behavior is not physically immutable storage.
| Situation | What the current SDK can establish | What it cannot establish alone |
|---|---|---|
| Someone changes a record after you retain its digest | A digest comparison exposes the mismatch | Who changed it or why |
| An editor corrects a record through the normal workflow | A new revision can preserve the old record and relationship | Whether the correction is factually justified |
| Someone rewrites the whole store, including its identities | An independently held earlier record/digest can expose disagreement when compared | A self-consistent replacement is not detectable from that replacement alone |
| Someone removes complete final log entries | An external record of the earlier extent can reveal missing history | Local verification alone cannot prove the store has not been shortened |
| Someone enters a false statement or date | Its later identity can be checked | Whether the original statement/date was true |
Keep separately controlled copies and expected identities if you need integrity across handoffs. Stronger protection against operator rewriting needs independent evidence. Independent timestamping, signatures and externally retained checkpoints are not verified by this alpha.
Does verified mean true, signed or independently timestamped?
No. Read each verification result separately. In 0.1.0, independent timestamp assurance is unavailable and signature assurance is none. Timestamp and provenance fields can preserve declared information; they do not constitute a verified timestamp proof or authenticated author identity.
An integrity match means the checked representation agrees with the expected identity. It does not prove the claim, the model's validity, the completeness of a publisher's forecast history or that a forecast was recorded before the outcome. Core concepts explains the separate identities and times.
How is this different from an internet crawler or web archive?
A crawler retrieves content. An archive preserves captures that can help show what a page displayed. The SDK gives selected evidence structured meaning: source assertion, separate interpretation, forecast question, outcome, correction and reproducible evaluation.
| Question | Crawl/archive | Current Comuvia SDK |
|---|---|---|
| What source page was captured? | Captured page and archive metadata | A record can reference retained source bytes and a locator; the SDK does not crawl |
| Which sentence made which claim? | A reader or another tool interprets the capture | A source assertion and selector identify the relevant content |
| What was predicted, under which conditions? | May be present as prose | Explicit records can preserve the question, forecast and declared timing |
| Why was a claim excluded from scoring? | Not the purpose of page capture | Named eligibility exclusions in the implemented binary evaluation |
| Can an old binary evaluation be reproduced? | May preserve its displayed result | Reproduction uses retained input records and the pinned scoring rule |
They complement one another. An archive capture can be an external evidence source; the SDK does not automatically submit to Archive.org or verify archive receipts. Archives can miss dynamic or inaccessible content, so an archive URL is not a promise of a complete capture. See the Library of Congress preservation guidance.
How is this different from registering a prediction on a blockchain?
A blockchain commitment can provide externally checkable evidence about a digest's inclusion in a ledger, subject to that system's trust and verification rules. The SDK organizes what the statement means and how to compare it with an outcome. These are different jobs.
The current SDK needs no blockchain, wallet or token and has no chain submission or proof-verification adapter. Blockchain timestamping could later be one optional assurance provider. OpenTimestamps is an existing example of a separate timestamp system; it is not a current Comuvia dependency or integration. Neither a chain entry nor a digest establishes that an economic forecast or political statement is correct.
Are hashes encryption? Can private articles remain private?
Hashes are fingerprints, not encryption. A digest does not hide an easily guessed short statement from someone who can hash candidate statements. Encrypting stored content is a separate application responsibility; the SDK is not an encrypted vault.
Applications can keep source bytes private and share permitted metadata, links and selected records. A reader without the underlying bytes cannot independently check their contents. A paywalled article need not be republished to describe a selected claim, but the publisher's rights still apply. Source evidence covers capture limits.
Does using the SDK register information with Comuvia?
No. The core is a local library, not a central registry. It does not upload records. The optional foreglass client performs explicit, bounded provider reads; it does not register a user's statements with ForeGlass. A future submission service would need its own consent, access, retention and review design.
Can every statement be scored as a forecast?
No. The implemented binary scoring rule needs an eligible declared event probability, matching question/outcome and required timing metadata. A quotation, conditional simulation or an extractor's confidence is not automatically a probability. Keep such material as evidence with explicit exclusions. See evaluation and reproduction.
Must the SDK be fully mature before it is published?
It needs to be dependable for the specific capability advertised. A narrow alpha need not implement every planned profile or service. The 0.1.0 release reflects engineering checks and reproducible builds, not proof of external adoption or a stable 1.0 contract.
Use the quickstart with the published package. Release status lists the approved file digests and how to verify a download.
Where should I report a problem?
Use GitHub private vulnerability reporting on github.com/comuvia/comuvia-sdk; the manually read fallback address is given in the repository’s SECURITY.md. Include versions, a minimal synthetic example, expected behavior and the observed result. Do not send private evidence or credentials. No response-time SLA is promised.