Platform overview
IntegraHive is a multi-tenant B2B data-integration platform. Trading partners deliver data over REST, secure file transfer, or direct upload; the platform infers the schema each file actually carries, versions that schema as a contract, stages the records, applies governance policy, quarantines what breaks the contract, and raises anomaly events — with tenant isolation enforced by the database rather than by application code.
This page is the entry point. It says what the system is, who it is for, what shape it has, and which document to read next.
What problem it solves
A platform that receives data from many partner organisations has three requirements that pull against each other.
Isolation must be absolute. The data belongs to organisations that are often competitors. A single cross-tenant leak is not a degraded experience; it is the worst outcome the system can produce.
Ingestion must be tolerant. Partners send malformed files, rename columns without notice, and change types between quarters. A pipeline that rejects everything unexpected is unusable. One that accepts everything silently is worse.
Everything must be reconstructable. When a downstream consumer asks why a number changed, the answer has to be recoverable from evidence rather than inferred.
Most of the design decisions documented here are that tension being resolved in one direction or another, deliberately.
Who it is for
Partners deliver data and check what happened to it. Machine-to-machine traffic authenticates with scoped API keys; people use a partner portal.
Operators run the platform for a tenant — reviewing quarantined records, approving or rejecting schema changes, promoting a contract version, investigating anomaly events. They sign in through enterprise SSO.
Downstream consumers read accepted data through a versioned API.
Shape of the system
Four intake channels converge on one pipeline:
land → infer → register → stage → govern → quarantine → detect
Convergence is structural, not conventional. Per-channel pipelines drift: the file-transfer path grows a quirk the REST path lacks, a governance rule is applied in one and forgotten in the other, and the divergence surfaces only when two partners with identical contracts produce different results. One pipeline means governance is written once and cannot be skipped by choosing a different door.
The runtime is Azure Container Apps across four workload types — web, workers, an ML service, and one-shot jobs — with managed PostgreSQL on a private virtual network and an internal-only NATS event spine. Nothing in the data tier has a public endpoint.
| Concern | Mechanism | Status |
|---|---|---|
| Intake | REST push, scheduled pull, managed file transfer, operator upload | Implemented |
| Schema | Deterministic inference, versioned contracts, explicit promotion | Implemented |
| Governance | Drift classification and per-dataset policy, applied before acceptance | Implemented |
| Quarantine | Reason-coded, retained, reprocessable | Implemented |
| Detection | Statistical and ML detectors raising severity-tagged events | Implemented; accuracy not characterised |
| Tenant isolation | PostgreSQL row-level security on a least-privilege runtime role | Implemented; end-to-end proof in progress |
| Delivery | Terraform per layer, OIDC federation from CI, gated apply, fail-closed guards | Implemented |
That last-but-one row is the one to read carefully, and it has its own page.
The load-bearing decision
Tenant isolation is a database policy, not a WHERE clause.
The conventional approach scopes every query in application code. It works until one query omits the predicate — at which point the failure is silent, returns more rows rather than an error, passes any test suite built on single-tenant fixtures, and exposes one customer's data to another.
IntegraHive moves that boundary into PostgreSQL using row-level security bound to a least-privilege runtime role that owns nothing and cannot bypass the policy protecting it. An application query that forgets its tenant predicate returns the rows the current tenant context permits, not everything. The application can still have bugs; it cannot have this bug.
What is implemented and what is proven are different claims, and the difference is the subject of two of the pages below.
What is deployed
A development environment runs the full stack. Staging and production are defined in code and not deployed. There are no customers, no production traffic, no uptime record, no benchmarks, and no certifications — and nothing published here quotes a figure for any of them, because none exist.
Where to go next
- Architecture — the runtime, data, messaging, identity, and delivery layers, and how they fit together.
- The governed ingestion pipeline — the seven stages every delivery passes through, and why they are in that order.
- Governance and quarantine — how policy is evaluated, what causes a record to be held, and why nothing is silently dropped.
- Tenant isolation — the isolation model, its boundaries, and its honest verification status.
- Operational evidence — the difference between a control working and evidence that it works, and what counts as evidence here.
- Engineering notes — the things that were harder, subtler, or more embarrassing than expected.
- Architecture whitepaper — the long-form version of all of the above, printable to PDF.