Does every customer get their own rules?
That is the question an enterprise architect asks first, and the answer decides the tenancy model, the isolation story and the commercial shape. The answer is: shared where the logic is universal, private where the content is yours, and never the two mixed.
// returned by the lane, signed before it is returned { "verdict": "accept", "lane": "dela.evidence-change", "reason": "material change in coordinates; 3 dependent analyses affected", "inputs": { "current": "sha256:9f2c…a71d", "candidate": "sha256:4b80…c2e9" }, "impact": { "affected": 3, "preserved": 41, "replayed": 3, "held_for_review": 1 }, "deterministic": true, "chain": { "index": 18274, "prev": "sha256:0c15…8fa2" }, "sig": "ed25519:7d41c0…9b3e" }
Every verdict records the exact rule version and input hash that produced it, so a result stays reproducible after the rule changes.
What is built, and what is a proposal
Most architecture pages blur the two. This one labels every claim, because an architecture reviewer who discovers halfway through that the diagram is aspirational stops reading, and they are right to.
Implemented and evidenced today, including in a third party's integration.
A recommended target design. Not built. Stated as a direction, not a capability.
A claim or detail that needs a test, a diagram, a cost record or a named owner.
The honest headline
The verification engine and its gates are implemented and have been integrated and tested by a third party. The enterprise scaffolding around them, tenant identity, rule governance workflow, formal isolation testing and a cloud reference deployment, is largely proposed. This is ready for an architecture validation sprint. It is not yet production-grade enterprise infrastructure, and we would rather say that here than have it discovered in a review.
Compositional rule resolution
Not one rulebook per customer, and not one rulebook for everyone. Three layers resolved at request time, with tenant identity established before resolution begins.
Shared core rules
Shared across all tenantsUniversal, non-sensitive logic. Unit conversions, mathematical invariants, chemistry, structural checks. Identical for everyone.
Industry packs
Shared within a sectorSector-specific rules that are common within a sector but not universal. Regulatory mappings, sector thresholds.
Where the line sits
A rule can be shared when its content is universal and non-sensitive. A unit conversion is the same in every organisation on earth. A private threshold, an internal reference or a restricted data policy is yours, lives in your overlay, and is not available to another tenant under any circumstances.
What a rule has to carry before it can run
A deterministic checker is only as trustworthy as the process that admits a rule into it. This is the minimum record.
| Field | Purpose |
|---|---|
| rule_id | Stable identifier. |
| scope | core, industry_pack or tenant_overlay. |
| owner | The person or organisation accountable for correctness. Not optional. |
| version | Immutable, and recorded inside every verification result. |
| effective_from / effective_to | Time validity, so a regulatory change has a date rather than a deployment. |
| input_schema / output_schema | What the rule accepts and what it returns. |
| test_cases | Expected pass, fail and boundary outcomes. Also not optional. |
| approval_state | Draft, reviewed, approved, retired. |
The governance rule
No rule version becomes active without an owner, test cases, a review status and an effective date. Not as a policy statement, as a precondition the system enforces. A rule nobody is accountable for is a liability wearing the costume of a control.
Reproducible after the rule changes
Every verification result stores the exact rule version and the input hash used to produce it. When the rule changes later, the original decision can still be reconstructed as it stood, which is the whole point of a control lineage layer rather than a policy document.
Difficult by construction, and testable
The right-hand column is the important one. Each control names the artefact a reviewer should ask us to produce, rather than the assurance we would otherwise offer instead.
| Control | Implementation | Evidence a reviewer should demand |
|---|---|---|
| Tenant identity | Signed token or OIDC identity maps to a tenant and a role. | A request trace showing the tenant binding. |
| Rule isolation | Core shared; private overlays in a tenant namespace with authorisation checks. | A cross-tenant negative test. |
| Data isolation | Tenant on every request, audit record and private object. Deny by default. | The data model and the access policy. |
| Encryption | TLS in transit, managed keys at rest, customer-managed keys as an enterprise option. | A written key and secret ownership decision. |
| Auditability | Request id, actor, rule version, result, timestamp and reason code. | A sample audit event and the retention policy. |
| Operational separation | Separate development, staging and production. No production data in test. | An environment diagram and the deployment policy. |
A boundary we will not blur
EcoKure should not be described as privacy-preserving merely because the evaluator is deterministic or can run offline. Those are properties of the engine, not of your data. Privacy depends on what enters the system, where overlays and evidence are stored, who can read them, and how deployments are isolated. Any vendor who conflates determinism with privacy is telling you something that sounds reassuring and is not an answer.
One engine, several shapes
Preserving one core engine across deployment forms is what avoids forcing every customer into the same data and network model. It is also why we can say the product is portable without that being a marketing line.
| Stage | Primary interface | Why it fits | Status |
|---|---|---|---|
| Pilot | Private API | Fastest path to demonstrating value, governance and usage figures. | Observed |
| High-isolation customer | Embedded package or customer-hosted service | Rule evaluation and data stay inside the customer's environment. | Proposed |
| Scaled product | Managed service plus enterprise private deployment | Commercial flexibility once the controls and the support model are proven. | Proposed |
The recommended starting point is a private API with a package-ready core. That is a starting point, not a commitment to one permanent hosting model, and the distinction matters to anyone whose data cannot leave their network.
The validation sprint, stated as work rather than as a claim
- One rulebook schema implemented, with the governance preconditions enforced rather than documented.
- One cross-tenant negative test that a reviewer can watch fail correctly.
- One latency and throughput benchmark with the environment, hardware, version and repeatability package attached, because a number without those is not a benchmark.
- One deployed pilot path, end to end, in a customer-shaped environment.
- Current hosting, account topology and production network documented. Today they are not, and that must be settled before any cloud migration or credit conversation is finalised.
- Retention, immutability and customer export policy for evidence, decided and written down.
Why this list is public
Because an architecture reviewer will produce it in the first hour anyway, and a company that hands it over unprompted is easier to work with than one that has to be walked into it. If you are that reviewer and this list is missing something, that is the most useful message you could send us.
Request the full architecture brief
The reference architecture, the gate interface surface, the tenancy control detail and the open decisions, sent under a mutual NDA. It is written for review rather than for persuasion, and it labels every proposal as a proposal.