[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"pCukmOJnuB":3},"# Pacioli\n\n_An attempt to build accounting on two honest halves: verified mechanics and\ncurated judgment._\n\n> **Status: first mechanics under way.** The charter below — the motivation and\n> the thesis — is settled, and the first verified mechanics are now being built\n> on top of it as small, rigorous increments, each worked through deliberately.\n> The first of these lands the entry/transaction substrate — double-entry\n> entries and the per-currency balance invariant — and, on top of it, the\n> asset/claim classification and the accounting equation (a balanced\n> transaction moves assets and claims equally), all in Lean 4. What follows\n> describes what Pacioli is _for_ and the shape it takes.\n\nPacioli proposes to split accounting into two cleanly isolated layers:\n\n- **The mechanics** — the deterministic, total parts of accounting, to be\n  codified in _Lean 4_ so that illegal states are unrepresentable and the\n  invariants that matter are machine-checked.\n- **The judgment** — the contextual decisions (policy, jurisdiction, timing,\n  materiality, classification), to be curated in the _Open Knowledge Format\n  (OKF)_ so that humans and AI agents can share the same auditable reasoning.\n\nThe ambition: Lean guarantees that _given_ a set of accounting inputs the\nmechanics are handled correctly; OKF guides the judgment about _what_ those\ninputs should be.\n\n---\n\n## Why this split\n\nMost attempts to formalize accounting fail because they try to prove judgment\ncalls. Revenue-recognition timing, impairment, fair-value estimates, and\nGAAP-vs-IFRS classifications are not mathematical theorems — they are shifting\npolicies. Forcing these fluid rules into a strict type system creates brittle\ncode that secretly hardcodes compliance policy, and it rots the moment an\naccounting standard changes.\n\nSo the seam is a single question, asked of every rule:\n\n> **Can this be made total and mechanical?**\n\nThat question sorts each kind of accounting work onto one side of the seam:\n\n|              | Yes → the mechanics (Lean)                                                                      | No → the judgment (OKF)                                                                                           |\n| ------------ | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| Nature       | Total functions, algebraic invariants                                                           | Policy, _\"it depends\"_, context                                                                                   |\n| Examples     | Double-entry balance, aggregation and rollup, period-close arithmetic, consolidation arithmetic | Revenue-recognition timing, depreciation-method choice, impairment triggers, materiality thresholds, GAAP vs IFRS |\n| Guarantee    | Machine-checked proof; illegal states uninhabited                                               | Auditable, cited, human- and agent-readable reasoning                                                             |\n| Changes when | The _mathematics_ changes (rarely)                                                              | A _standard or policy_ changes (often)                                                                            |\n\nSome statements straddle the seam on purpose. The **accounting equation**\n(`assets = liabilities + equity`) is the canonical one: it needs each account\n_classified_ as an asset, liability, or equity — that classification is\njudgment — and _then_ a mechanical theorem that the classified parts sum\ncorrectly. It is not one side or the other; it is a judgment input plus a\nmechanical proof, meeting at the seam.\n\n---\n\n## The interface contract (the crux)\n\nThe two halves are meant to meet at exactly one kind of handshake, and keeping\nit clean is the whole design:\n\n> A judgment (an OKF concept) produces **inputs** — plain data — and the Lean\n> kernel consumes those inputs **deterministically** and guarantees the\n> mechanics. The kernel neither knows nor cares _why_ the inputs are what they\n> are.\n\nIllustratively: a policy for how to recognize revenue over a contract is\njudgment; from it a recognition _schedule_ is produced — just amounts and\nperiods; and the kernel's job is to prove the resulting postings satisfy the\nmechanical properties it is responsible for (that they balance). The intent is\nthat this seam be real — a typed, checkable artifact — rather than a human\ncopying a number from a document into code.\n\nThe invariant that protects the seam: **policy never leaks into Lean types.** If\na Lean type could only be constructed by making a policy choice, that choice\nbelongs in OKF instead.\n\n---\n\n## Design principles\n\n1. **Make illegal states unrepresentable first, prove second.** Use Lean's type\n   system so that, e.g., an unbalanced transaction cannot even be _constructed_.\n   This buys much of the safety for little proof effort.\n2. **Reserve full proofs for load-bearing invariants.** A handful of theorems\n   the rest rests on, not one proof per rule.\n3. **Policy never leaks into types.** When in doubt, judgment goes to OKF,\n   mechanics to Lean.\n4. **Determinism at the boundary.** Everything Lean touches is a total function\n   of explicit data inputs — no hidden policy, no I/O, no ambiguity.\n5. **Rigour over speed.** Small, complete, well-explained increments. A proof\n   that is partial is not finished; there are no deadlines.\n6. **Everything is citable.** Lean invariants trace to their mathematical\n   source; OKF concepts trace to the standard or literature that justifies them.\n\n---\n\n## Toolchain rationale\n\n**[Lean 4](https://lean-lang.org/)** is the intended home for the mechanics: it\ncombines real dependent types, a growing and well-supported ecosystem (mathlib,\nan active community), a genuine programming language that also proves theorems,\nand compilation to a portable binary. The nearest serious alternative for\n\"verified software\" alone is **F\\*/Dafny** (SMT-backed refinement types, often\nmore ergonomic for pure verification), but part of Pacioli's value is being a\n_citable formalization adjacent to mathematics_, where Lean's community gravity\nand proof culture win.\n\n**OKF** ([Google Cloud, 2026][okf-spec]) is the intended home for the judgment:\na vendor-neutral, git-shippable standard — a directory of markdown files with\nYAML frontmatter, one concept per file — already structurally aligned with how\ncoding agents store curated memory. That alignment means the judgment half is\nnatively readable by the agents meant to consume it.\n\n[okf-spec]: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md\n\n---\n\n## The mechanics, in code\n\nThe Lean library is documented module-by-module — with a dependency diagram, the\nseam, and the theorem chain — in **[docs/architecture.md](docs/architecture.md)**.\n\n---\n\n## How this is meant to be used\n\nPacioli is built for **agent–human collaboration**. The intended loop:\n\n- A **human brings an input** — an idea from accounting literature, a new\n  standard, a policy question, a worked example.\n- An **agent (or human) updates the repository** — deciding whether the input is\n  _mechanical_ (a Lean invariant) or _judgment_ (an OKF concept), and making the\n  change while keeping the halves and the interface between them clean.\n- The **judgment half** then says _what_ the accounting inputs should be and\n  _why_; the **mechanical half** guarantees that, given those inputs, the\n  mechanics are correct — by construction and by proof.\n\nThe human supplies intent and judgment; the agent translates it into verified\nmechanics and curated knowledge.\n\n---\n\n## Status & license\n\nThis repository has moved from charter into its first mechanics: the thesis\nabove is settled, and the mechanics are built from the ground up as small,\ndeliberately worked increments — the entry/transaction substrate and the\naccounting equation (`assets = claims`) first — rather than quickly.\n\nLicensed under the **[Apache License 2.0](LICENSE)** — a permissive,\nOSI-approved open-source license (the same one used by Lean core and mathlib),\nwhich also carries an explicit patent grant. Free to use, modify, and\ndistribute, including commercially, under the terms of the license.\n",1784670031908]