Eridanos + Ariadne / Data foundations
Data integration with operational meaning.
Counterfold connects approved business data and builds an operational ontology: a shared model of the objects, relationships and rules that matter to your decision. Integration brings records together; the ontology explains how they relate.
Start with the decision and its sources
An integration plan begins with ownership, access, freshness and meaning. An API response, database table, spreadsheet export or report can each be useful, but each has different reliability and update requirements.
We identify keys, units, time zones, valuation dates and source precedence before connecting a workflow. Missing or contradictory evidence remains an exception rather than disappearing into a combined score.
An ontology is more than a field dictionary
A dictionary can define an account ID. An operational ontology can connect that account to an entity, its cash restrictions, an upcoming obligation and the actions that may be considered. Relationships and constraints make a change interpretable.
The model is specific to the operation. An airline may need aircraft, rotations and maintenance events; a hospital may need capacity, staff and diagnostic queues. The useful level of detail is established with the people who own the process.
What we build and verify
- Source mappings and reproducible ingestion appropriate to the systems.
- Identity resolution, duplicate checks and data-quality exceptions.
- Versioned definitions for entities, relationships and important measures.
- Provenance from a derived result back to its contributing records.
- Permissions and retention rules designed around the intended use.
A foundation that supports the next question
After one workflow is accepted, reusable definitions and source mappings can reduce the work needed for a related question. Reuse still requires checking its purpose, permissions and assumptions.
A small first implementation can use approved exports before a live integration is justified. We assess freshness needs, error handling and operating responsibility before expanding.
Practical answers
Questions before the first conversation.
Do we need a data lake first?
Not necessarily. The architecture follows the use case, source systems, volume and access requirements. A pilot may start with controlled exports or targeted connections rather than a company-wide migration.
Does an ontology automatically enforce security?
No. It supplies context and relationships. Authentication, data filtering, tool permissions and checks at execution must enforce access independently.
Can documents be part of the model?
Yes, where extraction and interpretation are appropriate and evaluated. Keep the original document, source references and uncertainty available for review; extracted text should not silently become an authoritative fact.