Every number traces back to a source
Quantivo treats provenance as a hard requirement, not a feature. Each stored value records where it came from, when it was acquired, when it was effective, which revision it belongs to, and the hash of the exact input that produced it.
What it does
Bitemporal by default
Acquisition time and effective time are stored separately, so you can ask what the system knew on a date as well as what was true on it.
Content-hashed manifests
Every derived record references an input manifest listing its exact inputs and their hashes. Recomputing from the same manifest must produce the same result.
Append-only lineage
Database triggers reject updates and deletes on lineage records. Corrections are new revisions that supersede, never overwrite.
No silent fallbacks
A module that cannot get real data reports empty, stale, or unavailable. It never quietly substitutes sample data for the real thing.
How it works
Record acquisition
Ingestion writes the source system, revision, and acquisition timestamp before any transformation runs.
Hash the inputs
A manifest enumerates the exact input records and their content hashes for the derived value.
Write append-only
Derived records are inserted with a revision number, and triggers enforce that prior revisions stay immutable.
Verify on read
Import and reconciliation paths re-verify manifest purpose, as-of time, entries, and hash before trusting a record.
Where this actually stands
Quantivo is being built in the open. This is what is running today and what is being worked on next — no roadmap items dressed up as shipped features.
Shipped today
- Data lineage policy governing every ingestion path
- Input manifests with content hashing and full manifest verification on import
- PostgreSQL trigger enforcement of append-only statement and outcome lineage
- Lineage API with authenticated access and audit logging
In progress next
- Extending manifest coverage to licensed market-data ingestion
- Retention and export redaction controls for entitled data (QVP-205)