Thanks Kurt. I do enjoy a good accounting example.
The immutable, write-forward ledger traces back to the original double-entry bookkeeping method. Contemporaneous documentation is a foundation of maintaining truth, even when it makes correcting errors challenging.
Maintaining historical values of accounts, based on posted dates, is foundational to accounting and periodic reporting. A company is still reporting and refining revenue for last month, while continuing to record more revenue this month. Imbedding historical account balances in the event log does not seem like the right model, and often would not even give the right answer to a relevant question. In this example, revenue to-date as of June 30th never shows up as a value in the event graph.
It also raises the question as to how often do you even need a current balance? You need to know the current bank balance, how many widgets you have in supply and the amount you owe supplier ABC. But many accounts balances you need only know when you report them. Employee costs last month is a query and never shows up as a current account value. Depreciation expense is a query that is dependent on the reporting purpose (book or tax.)
An alternative approach may be to periodically "close the books" and record an historical value of a fluent at a point in time, and then calculate the current value of a fluent based on a query of the event log and the last posted value. You could close the books monthly, or even daily, but you would not need to save the current and prior revenue account balance every time you made a sale.
Thanks again. Testing the holon architecture against these real-life accounting problems is sure be insightful.
• Universal Micro-Ledger Pin: Standardizes {holon}/events so auditors, AI agents, or ERPs can process it.
• Multi-Taxonomic Projections: Via XBRL GL SRCD, one event graph dynamically projects into IFRS, US GAAP, or Tax Named Graphs without data duplication.
We formalized this evolution in our Accounting & Audit by Design (A&AD) paper:
Thanks, Richard - these are very useful. We are in the process of standardising the schema (what is here is largely intended for showing the shape of the problem, not a finalised ontology), and making these consistent (or at a minimum interoperable) with existing architectures is a very significant part of our current efforts.
Thanks Kurt. I do enjoy a good accounting example.
The immutable, write-forward ledger traces back to the original double-entry bookkeeping method. Contemporaneous documentation is a foundation of maintaining truth, even when it makes correcting errors challenging.
Maintaining historical values of accounts, based on posted dates, is foundational to accounting and periodic reporting. A company is still reporting and refining revenue for last month, while continuing to record more revenue this month. Imbedding historical account balances in the event log does not seem like the right model, and often would not even give the right answer to a relevant question. In this example, revenue to-date as of June 30th never shows up as a value in the event graph.
It also raises the question as to how often do you even need a current balance? You need to know the current bank balance, how many widgets you have in supply and the amount you owe supplier ABC. But many accounts balances you need only know when you report them. Employee costs last month is a query and never shows up as a current account value. Depreciation expense is a query that is dependent on the reporting purpose (book or tax.)
An alternative approach may be to periodically "close the books" and record an historical value of a fluent at a point in time, and then calculate the current value of a fluent based on a query of the event log and the last posted value. You could close the books monthly, or even daily, but you would not need to save the current and prior revenue account balance every time you made a sale.
Thanks again. Testing the holon architecture against these real-life accounting problems is sure be insightful.
Separating identity, event history, and state into distinct holon graphs via Turtle 1.2 reification (~) is spot on, Kurt Cagle & Chloe Shannon!
However, there is a missing bridge: if holons log deltas with ad-hoc RDF properties (Event:deltaValue), global auditability collapses.
To fix this, we update the 2009 W3C XBRL Reporting Chain (https://www.w3.org/2009/03/xbrl/old-report.html) toward the Semantic Web by bringing XBRL GL (xbrl.org) directly into the graph:
• Universal Micro-Ledger Pin: Standardizes {holon}/events so auditors, AI agents, or ERPs can process it.
• Multi-Taxonomic Projections: Via XBRL GL SRCD, one event graph dynamically projects into IFRS, US GAAP, or Tax Named Graphs without data duplication.
We formalized this evolution in our Accounting & Audit by Design (A&AD) paper:
Overview: https://seattlemethod.blogspot.com/2026/07/accounting-audit-by-design-framework.html
Paper (PDF): https://github.com/AI2Accountans/AAxD/blob/main/AA_D_en.pdf
Bringing XBRL GL into the Holon's Event Graph is the missing link to turn semantic accounting into an enterprise-grade reality!
Thanks, Richard - these are very useful. We are in the process of standardising the schema (what is here is largely intended for showing the shape of the problem, not a finalised ontology), and making these consistent (or at a minimum interoperable) with existing architectures is a very significant part of our current efforts.