Systems & AI
Event Intelligence — computing what follows when something happens.
Monitoring tells you the state of the world now. Forecasting tells you what might happen. Neither answers the question that costs money: when a specific thing happens, who bears the consequence, in what amount, over what period, along which contracts — and what does the world look like afterwards, so that the next event lands on the changed world rather than the original one.
A chiller fails
A chiller fails in a commercial office tower on a Friday afternoon in August. Ask a large organisation what happens next and you get partial answers from different directions, none of which is the answer.
The building-management system knows the chiller is down and raises an alarm. The contractor knows the repair cost and the lead time. The property manager knows the tenants will complain. The insurer will eventually know whether a claim was filed. The lender holding the mortgage knows nothing at all, and will not for months.
The question that matters — what does this cost, to whom, over what period, and what should we do about it — has no owner and no system.
Follow it outward. Tenants have abatement rights that trigger at a defined threshold, at a rate set in the lease. The landlord has a service obligation with penalties, and a decision about emergency rental at a cost that may or may not be less than the abatement it prevents. Business-interruption cover has a waiting period and a definition of covered loss; the equipment-breakdown policy has a joint-loss provision determining which of two carriers pays when cause is disputed. Income falls, so net operating income falls, so capitalised value falls, so a loan covenant is closer than it was. And if this is the third failure this year, the insurer reprices the whole account at renewal — a consequence caused by accumulation rather than by any single event, and invisible to a system looking at one incident at a time.
Many of these consequences are individually computable, and specialist systems already handle parts of the problem well. What is usually missing is a single representation that carries the event across operational, contractual and financial boundaries while preserving attribution, state and evidence.
In practice the answer is assembled manually across functions, with different assumptions, time horizons and evidence standards. The difficulty is not a lack of capable specialists — it is that few systems are designed to carry consequence across all of these boundaries, and most are optimised, appropriately, for one part of the chain. The boundaries are exactly where the consequence travels.
Now change the event and keep the structure. A counterparty defaults. A hurricane makes landfall. A regulator issues a consent order. A supplier's plant floods. A control system is compromised. In each case an event occurs and its consequence propagates along contracts, ownership and obligation, changing the state of the world as it goes. The generality is the point: the machinery does not care whether the event is a chiller or a default, because the shape of the problem is identical.
Why this is built like a platform company
The clearest way to explain the structure is by comparison, and the comparison is deliberate.
In 1984 Apple did not sell people an operating system. Nobody woke up wanting a windowing server. What people wanted was to lay out a newsletter without paying a print shop, and what they bought was a Macintosh that ran PageMaker. But Apple did not become what it became by selling PageMaker. It became that because the same machine also ran Excel, and then Photoshop — and each new application cost less to build than the one before it, because the operating system had already solved the hard, universal problems. Microsoft made the same trade from the other end, licensing the machinery rather than the machine.
Kindynos is designed around a comparable architectural principle: solve the domain-independent execution problems once, then use the same foundation across multiple applications. Whether that produces platform economics is a separate question, and it remains to be demonstrated through outside authorship, repeated delivery and customer use.
EOS — the kernel, and why it is small on purpose
When an event is fired at a world, something has to work out which things it touches, call the right models to value them before and after, carry forward whatever changed, work out who bears the gain or loss and in what proportion, record where every number came from — and, when it cannot do one of those properly, stop and say so.
That last item is the whole point. Every risk system returns a number. But a number produced because a model was missing and the system quietly defaulted to zero looks exactly like a number that was properly computed — on the screen, in the report, in the board pack, in the filing. You cannot tell them apart afterwards, because the information was destroyed at the moment of substitution. EOS refuses instead: it names what is missing, marks the value as not computed, commits nothing, and exits with an error code.
EOS is 5,435 lines of core code; EVA, the application, is several hundred thousand. A core that size makes direct code review and bounded conformance testing practical in a way the larger estate does not — though meaningful assurance still depends on specifications, dependencies, tests and the surrounding execution environment. When the product is trustworthiness, being small enough to check is part of the product.
The kernel also knows nothing about any industry. Everything domain-specific lives in the authored world, outside it — and that has been tested mechanically rather than asserted: a domain the kernel had never encountered was authored, run end to end, and the kernel then searched for any word belonging to it. Zero matches, and the test stays in the suite.
EPL — the language
EPL is how a world is described. You do not write code; you write down what exists — these are the assets, these are the parties with a stake in them, this is what they owe each other under what conditions, this is the event, this is what it changes. The kernel compiles that into a neutral intermediate form and executes it. If a domain expert can author a world without a software engineer present, the marginal application becomes an authoring exercise rather than an engineering project. That is the platform thesis, and it is unproven — the test that would settle it, an outside expert authoring a working world unaided, has not been attempted.
EVA — the application
EVA is the customer-facing layer: the application through which an event, a represented world and the resulting consequences become usable analysis. Give it an event and a world, and it returns which assets are affected, how their cashflows and values change, who bears the gain or loss measured in their own terms, what the world looks like afterwards, and the evidence behind every number.
A world is modelled as authored, typed objects rather than parameters: events with classifications, typed inputs and declared reach; assets carrying valuation-relevant features; stakeholders carrying utility weights, so the same physical loss is correctly a different loss to a reinsurer, a regulator and an operating business; conditions that persist and modify the terms under which later events fire; and explicit matrices binding event to asset, event to stakeholder, and asset to stakeholder, so the propagation path is inspectable rather than inferred.
Roughly seventy ecosystems have been authored across cyber, climate, supply chain, energy, infrastructure, insurance, banking, housing, real estate and equities among others. A count of ecosystems is not an asset register: some are complete enough to defend before a committee, others are demonstrations, and quality varies materially. What the count establishes is that they are all the same shape, which is why one engine runs all of them. Whether that materially lowers the cost of the next world is the platform question, and it remains to be demonstrated.
Four ways to interrogate a world
A described world is a representation, not a single-purpose model. Four genuinely different disciplines interrogate it, and they map onto time and action.
- Risk — forward. Probability and consequence over events that have not occurred.
- Forensics — backward. Attribution of a realised outcome to its cause, and to who bears it.
- Investment — present. Valuation, exposure, sensitivity, what to pay.
- Decision — action. The best move when other parties are choosing too, and their choices change your payoff.
The fourth is the differentiator and the least common. Consequential decisions are not made against nature; they are made against other decision-makers. An insurer deciding whether to renew a book is choosing against competitors who may also exit — and if enough exit together, the market breaks and remaining capacity reprices violently.
The machinery is explicit: payoff matrices with the opponent's available actions enumerated, per-cell utilities computed through the same consequence engine, equilibria and saddle points identified and marked. Credibility in this layer comes from exposing the machinery, not from presenting the verdict — an investment committee will accept a recommendation only when it can see the payoff structure that produced it. And it inherits the engine's memory, so a state's value depends on the action history that reached it: the decision problem is path-dependent by default.
Implemented capabilities exist across the four layers and several domains at materially different levels of maturity. The grid is the organising architecture; individual cells should be described and demonstrated separately rather than claimed together.
Where it actually stands
Stated before anyone asks, because the central claim of the work is a disciplined refusal to overstate what is known, and a page that overstated it would be self-refuting.
- EVA is an extensively developed, pre-commercial software and research estate. It is not a customer-deployed production service, and nothing in the portfolio is in production use by a paying customer.
- The strongest evidence is on bounded deterministic, refusal and provenance paths. The firing path is locked to a byte-identical baseline by a named test, and a named test asserts fail-closed behaviour where a value cannot be resolved. Maturity varies materially across the wider estate, and those results should not be generalised to it.
- Coverage is deliberately incomplete. Many event-to-model bindings return "not computed" where no researched model exists. That is the correct posture, and it means seventy authored ecosystems are not seventy fully valued worlds.
- Stakeholder reaction is implemented and tested as a subsystem, and is not on the firing path. The precise claim is that reaction is modelled as a game solved at quantal response equilibrium at subsystem level — not that firing an event causes stakeholders to react and that reaction to feed back into the consequence.
- One architecture authority. Current work focuses on live-data integration, stronger conformance, and extracting a smaller independently reviewable execution core. There is a single author, which is the largest single point of failure and is named here rather than discovered.
Capability is tracked against a register recording, for each named capability, whether it is demonstrated, implemented, authored, designed, researched, or a direction. A capability present in a repository is not the same as one invoked on the path that produces the answer a user sees. A fuller technical status document is available for diligence.
What this is worth to a role or a mandate
The point, for an employer or a sponsor, is not that I have written software. It is that I can move from a difficult domain problem to an explicit analytical architecture, direct its implementation, identify where its outputs are not trustworthy, and explain the result to executives, investors, regulators, quants and engineers.
The most useful evidence I can offer for that is not a feature. It is a defect I found in my own system. An allocating world reported a consequence of +216,502.33 to a stakeholder holding a position that had lost 16.92 — wrong sign, wrong by four orders of magnitude, stamped reliable, and present since an early build. Every regression test passed throughout, because every anchor in the suite constrained magnitudes and none constrained attribution. The totals were right; the split beneath them was wrong. A green test suite is evidence about what was tested and nothing more — which is the same judgement that matters when the system under review belongs to someone else.