The warehouse
How Rillor operates a dataset.
Rillor is not a generic cloud database or self-service storage product. It builds and operates dataset assets: source acquisition, preservation, labeling, entity resolution, normalization, provenance, versioning, quality review, and maintenance.
Collect. Label. Normalize. Maintain.
One vocabulary, used everywhere. Governance and verification apply across every stage rather than sitting beside them as a fifth step.
| Stage | What happens | Retained output | Governance applied |
|---|---|---|---|
| Collect | Acquire and preserve source material together with origin metadata and applicable rights information. |
| Acquisition constraints and source rights review. |
| Label | Identify records, entities, attributes, relationships, and the evidence class each value belongs to. |
| Label vocabulary control and review of ambiguous cases. |
| Normalize | Reconcile structures, identities, units, terminology, and time without erasing the source record. |
| Lineage is retained so a value can be traced to its source. The lineage state reached by each dataset is declared on its record. |
| Maintain | Version datasets, track changes, review quality, reconcile conflicts, and publish limitations. |
| Lifecycle state and declared limitations are kept current. |
This is the standard Rillor applies as a dataset advances — not a claim that any given dataset has already cleared every stage. What a dataset retains today is declared on its own record.
“Maintained” describes an engagement-specific capability. It is not a universal freshness or service-level claim for a registry entry.
Shared governance, separate data planes
Rillor operates shared governance and catalog infrastructure over separate domain data planes. Each domain keeps its own structure, review, and lifecycle.
Not every domain is flattened into one physical database.
Control plane
- catalog
- governance
- lineage
- lifecycle
- access policy
Data plane 01
Legal authority
Data plane 02
GPU systems and pricing
Data plane 03
Federal procurement
Data plane 04
Communications and markets
Custom engagements are provisioned as their own plane under the same governance.
Control 01
Identity and versions
Stable identifiers, source-aware resolution, effective dates, and reproducible releases.
Control 02
Rights and lineage
Source categories, acquisition basis, transformations, and downstream dependencies remain attached.
Control 03
Freshness and quality
Declared objectives, reconciliation evidence, exception handling, and visible data limitations.
Control 04
Access and support
Delivery modes, security class, retention, licensing, and support boundaries advance together.
Versioning and governed change
Every dataset is versioned, and each version carries its own change record. Datasets move between governed states, and every move is a reviewed decision rather than an automatic one.
A dataset advances only when its ownership, source rights, lineage, freshness, quality, delivery, security, retention, support, licensing, and limitations are declared and reviewed. The same review governs a move in the other direction. What a dataset retains is declared on its own record.
Quality controls
These are the controls a dataset is held to as it advances.
Conflict reconciliation
Disagreeing observations are resolved with the decision retained, not overwritten.
Evidence separation
Classes are never blended into a single unlabelled value.
Change detection
Source revisions and withdrawals are detected and versioned.
Published limitations
What a dataset cannot support is documented alongside what it can.
No unreviewed figures
Counts and rates are not published until regenerated and reviewed.
Delivery principles: nothing ships anonymously or self-service. Coverage, schema, authentication, rate limits, cadence, versions, rights, and support are defined per engagement.
Request data