The rules, and who owns each one
Most vendors in this category treat the rulebook as the secret. We publish the core, because the rules are not the moat. The moat is that they are deterministic, versioned, testable, and that you can run them yourself and find where they are wrong.
Not three rulebooks. One, composed three ways.
A separate rulebook per customer means every customer is a maintenance burden and none of them benefit from a fix made for another. A single rulebook for everyone means your private thresholds live in a file other organisations can reach. Composition avoids both.
Universal, non-sensitive logic
A unit conversion is the same in every organisation on earth. So is a molar mass, an arithmetic identity, a dimensional balance. There is no version of these that belongs to one customer, and pretending otherwise would mean maintaining the same rule many times and fixing it once.
Owned and versioned by EcoKure. Published below.
Sector-common, not universal
Materiality thresholds, regulatory mappings, reviewer routing conventions. Common enough within a sector to be worth building once, specific enough that they do not belong in the core.
Owned by EcoKure with domain review. None are built yet, and the sketches below are direction rather than product.
Your rules, and only yours
Private thresholds, internal references, restricted data policy, the workflows that may never be auto-approved. Resolved at request time after tenant identity is established, never visible to another tenant, and never merged into the core.
Owned by you. If you leave, it leaves with you.
The 10 core rule families, published
Each decides one narrow question exactly, or declines to decide it. Most are public repositories you can clone and run against your own cases today.
ClaimGate
Interactive labExtracts claims from AI or scientific output and routes each one to the deterministic gate that can settle it.
UnitGate
Interactive labDimensional-analysis checker for physics equations. Catches equations that cannot be right regardless of the numbers.
ElementGate
Interactive labChemistry validator covering formula parsing, molar mass and reaction balancing against a known-compound registry.
StatsGate
Open sourceDetects impossible or internally inconsistent statistics using GRIM and p-value consistency checks.
TheoryGate
Open sourceDeterminizer for mathematics and physics theory claims, returning exact verdicts rather than opinions.
ChipGate
Open sourceStructural sanity checker for Verilog RTL. Finds undriven outputs, multi-driven signals and unintended latches.
MedGate
Interactive labClinical decision-support checks covering dose binding, oncology dosing limits, interactions and paediatric restrictions.
ClaimLint
Open sourceLints documentation for unsupported AI and science claims. Runs as a CLI or a GitHub Action in CI.
MathGate
Open sourceExact-arithmetic engine producing replayable certificates. 1,116 of 1,116 ProofBench-X cases pass and reproduce.
Security Lanes
Open sourceReproducible test cases across CWE and OWASP weakness families with transparent scoring.
Why publishing the core costs us nothing
A competitor can read every one of these. What they cannot copy is the non-public record of registered attacks and the cases where each rule was found wrong and hardened, which is the part that took the time. Publishing the rules and withholding the failure history is the opposite of what most vendors do, and it is the right way round.
What a sector pack would contain
None of these are built. They are shown so a prospective customer or partner can tell us where the sketch is wrong before we build the wrong thing. The first one gets built with a design partner, not in advance of one.
Regulated life sciences
ProposedCore it builds on
Pack rules it would add
- Evidence-version materiality thresholds for structural and reference data
- Revalidation triggers mapped to change type
- Reviewer routing for clinical and scientific judgement cases
- Evidence-pack format shaped to validation and inspection expectations
What stays in your overlay
- Your product-specific acceptance limits
- Your internal reference standards and their versions
- Which of your workflows may never be auto-approved
Financial services and insurance
ProposedCore it builds on
Pack rules it would add
- Control-change detection mapped to obligation registers
- Decision-record completeness checks for model-informed decisions
- Retention and reconstruction rules for prior decisions
What stays in your overlay
- Your thresholds, limits and risk appetite statements
- Your internal policy references
- Which decisions require a named human approver
Aerospace and safety-critical
ProposedCore it builds on
Pack rules it would add
- Envelope and operational-limit constraint families
- Fail-closed permission contracts for actuation paths
- Authorisation and override recording requirements
What stays in your overlay
- Your platform-specific limits
- Your authorisation matrix
- Which actions may never be permitted automatically
The part we never see the inside of, and never share
| Question | Answer |
|---|---|
| Who owns it | You. Authorship, content and lifecycle. It is your policy expressed as rules. |
| Who else can read it | No other tenant, under any composition. Overlay resolution happens after tenant identity is established, and a private object is denied by default. |
| Can it override the core | It can tighten, not loosen. An overlay may add a constraint or narrow a threshold. It cannot make the core approve something the core would block, because that would let a rulebook edit disable a control. |
| What happens if you leave | It goes with you. It is your content, exported in the format it was authored in. |
| What we can see | That a rule ran and what it returned, for support and billing. Publishing exactly what we can and cannot see is part of the pilot agreement rather than a policy page. |
Tighten but not loosen: the reason for the rule
If a customer overlay could override a core block, then anyone with rulebook edit rights could quietly disable a safety check, and the resulting evidence pack would still look clean. That is a control system that can be turned off from the inside without leaving a mark, which is the one failure mode this entire product exists to prevent.
What is published, and what is not built yet
Published today
- The core rule families, with what each does not check.
- Source for most of them, runnable against your own cases.
- The composition model and the tenancy controls.
- The rule record every rule must carry before it can run.
- Our own retractions and the defects we found in our code.
Not built yet
- Any industry pack. The sketches above are direction, not product.
- Rule-level versioning and approval workflow as an enforced precondition rather than a documented intention.
- A customer-facing overlay authoring interface. Today an overlay would be built with us during a pilot.
- A published rule catalogue with owners, versions and test cases per rule. That is the destination, and it needs the rule record implemented first.
The order this gets built in
The rule record and its enforcement come first, because a pack built before versioning exists is a pack that cannot be governed. The first industry pack then gets built with a design partner who needs it, not speculatively in advance of one. If that partner is you, the pack is shaped around your workflow and the parts that are genuinely sector-common become core for everyone afterwards.
Tell us where the sketch is wrong
If you work in one of these sectors and the pack outline above is missing the rule that actually causes you pain, that is the most useful message we could receive. It is also how the first pack gets built correctly.