Deploy the E-stack within your boundary.
The E-stack connects qualified computational reuse, verification, change-aware evidence and action authority. This deployment view explains shared logic, private control context, rule governance and the enterprise operating layer that still requires validation.
A shared verification engine.
Universal checks can be reused across customers without exposing customer-specific thresholds, data or reviewer policy.
Built and published where the rule is genuinely universal.Customer context is resolved last.
The tenant identity, Control Pack, private thresholds and approved review routes are joined at request time so another customer cannot inherit your operating context.
Tenant isolation and production controls remain validation gates.Every result can show its lineage.
The rule version, input digest and outcome travel with the record, making a later reconstruction possible even after the source or rule changes.
A reproducible record is not the same thing as a legal certification.Your environment / Declared boundary
Place each permission where it belongs.
Explore the identity, evidence and action boundary to qualify for your environment.
Select an illustrated object to inspect its role.
01 / 03
Declare who can see and request the work.
Map organisation membership, access to records and the requested workload before integration.
Environment-specific access reviewTenant isolation and enterprise operating guarantees require evidence for the exact deployment.
What is built, and what is a proposal
The verification engine is built. The enterprise operating layer is the part still being validated.
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.
Read the full status boundary
The honest headline
The verification engine and its gates are implemented and have been integrated and tested by a third party. Tenant identity, rule governance workflow, formal isolation testing and a cloud reference deployment are largely proposed. This is ready for an architecture validation sprint; it is not yet production-grade enterprise infrastructure.
How customer rules stay separate
Shared logic stays shared. Customer-specific rules stay private. Three layers are combined only after the tenant is identified.
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 shared logic ends and private data begins
A rule can be shared when its content is universal and non-sensitive. A unit conversion is the same in every organisation. A private threshold, internal reference or restricted data policy belongs in the tenant overlay and is never available to another tenant.
What must be true before a rule runs
Every active rule needs an owner, a version, tests, and an effective date. The system should reject incomplete rules.
View the minimum rule 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.
How isolation is checked
Each control has a corresponding piece of evidence a reviewer can request. The table stays available when you need the implementation detail.
View tenancy controls and reviewer evidence
| 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. |
Read the privacy and isolation boundary
A boundary we will not blur
Determinism and offline operation describe the engine, not your data. Privacy depends on what enters the system, where overlays and evidence are stored, who can read them, and how deployments are isolated.
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.
Compare deployment shapes
| 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
View the validation sprint checklist
- 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.