System
Reference

Status: draft v0.2
Companion to: Memorandum on Accounting v0.3 (the SSOT)
Purpose: describe the modules of a complete accounting system and the specifications that make rules portable across systems and authorities

1. The core idea

A complete accounting system, built today, is two things bolted together:

• A generic engine that captures economic events, runs deterministic processes, projects results into the views every stakeholder needs, and submits them through standard transports.
• A library of rules issued by external authorities — tax authorities, statutory bodies, accounting standard-setters, sector regulators — in machine-readable, signed, versioned form. The engine does not contain the rules; it loads them.

The separation is the architectural commitment that follows from §4 of the SSOT (the three rule strata change at three different rates and must be addressable independently). Every module in this document is on one side of that line: either generic engine, or a place where authority-issued rule packs are loaded, indexed, executed, and managed.

The same engine, loaded with Latvia's rule packs, runs as a Latvian accounting system. Loaded with Estonia's, it runs as an Estonian one. Loaded with both plus an IFRS pack, it runs as a multi-jurisdictional reporting system. The engine never changes.

2. Module map

┌───────────────────────────────────────────────────────────────┐
│                    AUTHORITY REGISTRIES                       │
│                                                               │
│  VID  │  Valsts Kase  │  IFRS  │  Peppol Authority  │  ...    │
└─────────┬───────────────┬───────────────┬──────────────┬──────┘
          │               │               │              │
          ▼               ▼               ▼              ▼
       Tax rules    Accounting rules  IFRS rules    Filing
       (UAPF)       (UAPF)            (UAPF)        transports
          │               │               │              │
          └───────────────┴───────────────┴──────────────┘
                                  │
                                  ▼
                       ╔═════════════════════╗
                       ║  RULE REGISTRY      ║   versioned, signed,
                       ║  (the loaded rules) ║   effective-dated
                       ╚═════════════════════╝
                                  │
                                  ▼
                          ┌──────────────┐
                          │  PROCESS     │   deterministic
   ┌───────────────┐      │  ENGINE      │   execution
   │  AI INTERP.   │ ───▶ └──────────────┘
   │  LAYER        │             │
   └───────────────┘             ▼
          ▲                ┌──────────────┐    ◀──── EVIDENCE
          │                │  EVENT STORE │           VAULT
   ┌───────────────┐ ────▶ │              │           (content-
   │  INPUT        │       │ append-only  │           addressed,
   │  ADAPTERS     │       │ hash-chained │           immutable)
   └───────────────┘       │ bitemporal   │
          ▲                └──────┬───────┘
          │                       │ project
          │                       ▼
          │                ┌──────────────┐
          │                │  KNOWLEDGE   │
          │                │  GRAPH       │
          │                └──────┬───────┘
          │                       │ query
          │                       ▼
          │                ┌──────────────┐    statutory statements,
          │                │  PROJECTIONS │ ─▶ tax returns, audit packs,
          │                │  (incl. the  │    management reports
          │                │   ledger)    │
          │                └──────┬───────┘
          │                       │
          │                       ▼
          │                ┌──────────────┐    Peppol, eDelivery,
          │                │  SUBMISSION  │ ─▶ tax-authority APIs,
          │                │  ADAPTERS    │    banking gateways
          │                └──────────────┘
          │
          ├──── API LAYER (humans + agents + auditors)
          │            │
          │            ├──── UI as privileged client
          │            └──── AUDITOR INTERFACE (read-only role)
          │
          └──── AUDIT TRAIL (cross-cutting)

Twelve modules, each with a defined role:

3. The data layer in detail

A common question about this architecture is: where is the database; where do the actual debit and credit values physically live?

The answer is that there are five physical data stores, each with a specific role and a specific tamper-evidence guarantee. They split into two layers — primary data (the source of truth) and derived projections (the read layer).

┌──────────────────────────────────────────────────────────────┐
│              DERIVED PROJECTIONS — read layer                │
│                                                              │
│   Ledger          Knowledge        Statutory      Tax        │
│   Projection      Graph            Statements     Returns    │
│   (general        (typed                                     │
│    ledger,        entities)                                  │
│    balances,                                                 │
│    sub-ledgers)                                              │
└─────────────────────────┬────────────────────────────────────┘
                          │
                  regenerate from
                          │
                          ▼
┌──────────────────────────────────────────────────────────────┐
│              PRIMARY DATA — source of truth                  │
│                                                              │
│    ┌──────────────────┐          ┌────────────────────┐     │
│    │  EVENT STORE     │ ◀──────▶ │  EVIDENCE VAULT    │     │
│    │  append-only     │   hash   │  content-          │     │
│    │  hash-chained    │   refs   │   addressed        │     │
│    │  signed          │          │  immutable         │     │
│    │  bitemporal      │          │  deduplicated      │     │
│    └──────────────────┘          └────────────────────┘     │
│             ▲                                                │
│             │ executed against                               │
│             │                                                │
│    ┌──────────────────┐                                     │
│    │  RULE REGISTRY   │   authority-issued UAPF packs        │
│    │                  │   versioned, signed, effective-dated │
│    └──────────────────┘                                     │
└──────────────────────────────────────────────────────────────┘

3.1 The Event Store — the source of truth

Append-only log of every economic fact the system has accepted. Each row is an event with this schema:

This is where the actual money values live. Every journal-entry posting is itself an event of type journal_entry_committed, with debit and credit amounts in its payload. The "ledger" you query is a projection over these events, not separate primary storage.

The previous_hash → this_hash chain makes the store tamper-evident: any modification of any past event invalidates every subsequent hash. The signature prevents forgery — the committer's private key is required to sign. No update or delete is supported. Corrections are new events that compensate the original (the storno pattern), themselves signed and chained.

Storage technology: an append-only table in a transactional database (PostgreSQL with strict no-update constraint), written sequentially. Periodically a Merkle root over recent events is exported to write-once-read-many medium and optionally anchored to external infrastructure (a notary, a public certificate-transparency log, a blockchain) for externally verifiable timestamps. The anchor is the Merkle root only — events themselves stay private.

3.2 The Evidence Vault — the source documents

Object storage, content-addressed (every file identified by SHA-256 of its content). Stores every original artifact: e-invoice XML, supplier PDF, photo of receipt, contract document, bank statement, signed authorisation email. Stored once, deduplicated by hash, never modified, never deleted.

The link from Event Store to Evidence Vault is the evidence_hash field. Modifying a document changes its hash, which breaks the linkage — another layer of tamper-evidence. Auditors verify nothing has been altered by re-hashing and comparing.

Storage technology: S3-compatible object store with object-lock enabled, or a filesystem with WORM guarantees, or both (replicated). Optional second copy in a different jurisdiction for regulatory sovereignty.

3.3 The Ledger Projection — the working accounts

What most accounting software calls "the database." In this architecture, it is a derived materialised view, not primary storage.

Every committed journal_entry_committed event in the Event Store contributes lines: account, debit, credit, period, currency, dimensional tags. The projection is incrementally maintained from the event stream. Account balances at any date are sums of contributing lines up to that date.

If the projection is destroyed, it is recomputed from the Event Store with no information loss. This is what gives reconstructibility (SSOT §6 quality 5) its operational meaning — the ledger is regenerable.

Storage technology: query-optimised relational database (PostgreSQL or similar). Read-heavy workloads served from columnar OLAP replicas. The projection is not the source of truth; it is the read layer.

3.4 The Knowledge Graph — the typed entities

Graph projection from events: parties, accounts, employees, assets, contracts, organisational units, with their relationships and current state. Re-derivable from the Event Store. Used for semantic queries — "show me all contracts with vendor X expiring in Q3", "what assets does cost centre Y own."

Storage technology: a property graph database (Neo4j, ArangoDB) or a relational schema with foreign-key relationships indexed for graph traversal. Same regenerability property as the Ledger Projection.

3.5 The Rule Registry — the loaded UAPF packs

Local cache of UAPF rule-pack files plus a manifest table. Each pack signed by its authority, version-tagged, effective-date-ranged. The Process Engine reads from this registry at runtime.

Tamper-evidence: signatures verified on load. Modifications to a cached pack would fail signature verification on the next read.

Storage technology: filesystem (one directory per authority, version subdirectories) plus a small metadata index in the database for fast queryability — which pack version is effective on date D for jurisdiction J?

4. Tamper-evidence model

The architecture does not rely on a single mechanism for tamper-evidence; it stacks six independent layers, each detectable, each verifiable by the auditor without the system's cooperation.

1. Hash chain in the Event Store. Each event includes the SHA-256 of the previous event. Modifying any historical event invalidates every subsequent hash. Detectable by re-walking the chain.
2. Cryptographic signatures. Every event is signed by its committer's private key (a human approver or an authorised agent). Forgery requires the key. Detectable by signature verification against the committer's published public key.
3. Content-addressed evidence. Source documents in the Evidence Vault are identified by SHA-256 of their content. Modifying a document changes its hash, which breaks the link from the event that references it. Detectable by re-hashing the document.
4. Append-only architecture. Database constraints prevent UPDATE or DELETE on the Event Store. Corrections take the form of new compensating events (the storno pattern). Detectable by schema and database-level audit logs.
5. Process re-execution. Any committed journal entry can be re-executed against the captured inputs and the recorded rule-pack versions. The output must match exactly. Detectable by re-running the Process Engine.
6. Optional external anchoring. Periodic Merkle roots over recent events are written to write-once-read-many storage, and optionally anchored to a public infrastructure (notary timestamp, certificate-transparency log, blockchain). The anchored root proves the events existed at the timestamp claimed, without revealing the events themselves. Detectable by external verification.

Each layer detects a different class of attack. Hash-chain detects insertion or modification within the chain. Signatures detect forgery of authorship. Content-addressing detects evidence tampering. Append-only constraints prevent the most common quiet edits. Re-execution detects code corruption or rule drift. External anchoring prevents the entire chain from being secretly rewritten by a system administrator.

This is stronger tamper-evidence than any current generation of accounting software offers. Most existing systems rely on database audit logs, which are themselves modifiable by anyone with database access.

5. The Auditor Interface

Auditors are first-class users in §3 of the SSOT (stakeholders 2 and 5 — tax authorities and sector regulators — both audit; internal auditors serve stakeholder 1; external statutory auditors serve stakeholders 3 and 6). The system exposes a dedicated interface for them, served from the same primary data through a distinct read-only role.

The auditor interface delivers seven specific capabilities:

1. Time-travel query. "Show me the books as of midnight 2025-12-31, under the rule versions active at that time." The system replays events through the rule packs of that period. Built on the bitemporal Event Store and the Rule Registry's effective-date index.
2. Provenance traversal. For any journal entry, single-click drill-down: which event triggered it, which AI proposal classified it, which rule pack version executed, which intermediate values, which approver signed it, against which evidence document. The chain is in the data, not assembled by a human.
3. Hash verification tooling. Re-hash events and evidence; re-walk the chain; verify signatures. Independently confirms tamper-evidence without trusting the system itself. Optionally verifies against an external anchor (notary timestamp, blockchain anchor) to confirm events existed at the claimed timestamp.
4. Process re-execution. Pick any journal entry; re-run the deterministic process against the captured inputs; confirm the output matches. Detects code corruption, rule drift, or tampering.
5. Anomaly and override report. Every entry where the human approver overrode the AI proposal; every entry where confidence was below a threshold; every storno (correction) and what it compensates; every exceptional path through the trust boundary.
6. Standard-format export. SAF-T, CaseWare schemas, ad-hoc CSV — generated as projections from the Event Store, not from a separate audit-data export pipeline. The auditor's external tools see consistent, regenerable data.
7. Scoping. Auditor credentials limited to entity X for period Y, with a query budget. Cross-tenant or cross-period access requires separate authorisation.

The structural improvement over today's audit is significant. Currently, auditors typically receive a SAF-T export, load it into CaseWare, and reconcile externally — losing the live verification loop, working from a frozen extract that may not match the source data, with no ability to verify cryptographically that the extract has not been altered. The new model keeps the auditor connected to the live system through a scoped read-only view, with verification tooling that confirms the data has not been tampered with at the moment of inspection.

6. The rule lifecycle — how authority decisions reach the system

This is the architectural feature that distinguishes this design from every previous generation of accounting software.

  Authority drafts        Authority signs          System polls
  new rule version  ──▶   and publishes       ──▶  registry
  in UAPF format          to its registry          on its schedule
                                  │
                                  ▼
  Effective on        ◀── System updates    ◀── Rule pack
  configured date          local cache &         downloaded,
                           process registry       verified
                                  │
                                  ▼
  Events whose effective     Audit trail records:
  date matches the new   ──▶ which version produced
  version run under it       which entry, when

Authority side. A rule pack is a directory of UAPF process artifacts plus a manifest. The manifest declares the pack's identity, version, effective date, signature, and dependencies. The authority publishes through a registry — a content-addressed HTTP endpoint, a Git-like mirror, or a sovereign distribution channel.

System side. Sledger (or any conformant runtime) subscribes to relevant registries. New versions trigger a verify-then-stage flow: signature checked against the authority's published key, regression suite run against the previous version's reference cases, conflicts surfaced if any. On the configured effective date, the new version goes live; events with effective dates inside the new range run under the new rules.

Properties that follow.

• Software releases decouple from rule changes. A tax-rate update is a rule-pack download, not a software deploy. The application itself is not in the change-management critical path.
• Reconstruction works. The Rule Registry retains every version with its effective range. Re-running a closed period uses the rule version that was in effect at the time, automatically.
• Multi-jurisdictional is configuration, not engineering. Adding Estonia is loading the Estonian pack alongside the Latvian one. The engine handles routing by event jurisdiction.
• Audit verification becomes mechanical. "Did this entity correctly apply VID's IIN rules in March 2026?" answers as a database query: which UAPF version was active, which inputs were marshalled, which outputs were produced, which approver signed.

7. The event lifecycle — what happens when something arrives

1.  Event arrives ──────────────▶  Input adapter normalises
       (invoice, bank line,            into canonical event +
        contract, payslip, etc.)        evidence reference

2.  Evidence hashed ─────────▶     Stored in evidence vault
                                    SHA-256 → immutable URL

3.  AI interpretation ────▶       Classifies event type, extracts
                                    fields, identifies applicable
                                    rule packs, marshals inputs.
                                    Output: a PROPOSAL with confidence.

4.  Process engine runs ────▶     Deterministic execution of the
                                    selected UAPF processes.
                                    Output: journal-entry candidate +
                                    structured reasoning trace.

5.  Approval queue ────────▶      Human (or authorised agent) reviews
                                    proposal + reasoning + evidence.
                                    Approves, rejects, or amends.

6.  Commit ──────────────────▶    Append to event store with full
                                    chain: AI proposal id, rule pack
                                    versions, intermediate values,
                                    approver identity, timestamps,
                                    hash chain link, signature.

7.  Projections refresh ───▶      Knowledge graph updates.
                                    Statutory views recompute.
                                    Submission queue updated where
                                    obligation thresholds are met.

Step 5 is the trust boundary. Rule selection (Step 3) is fuzzy work, AI's domain. Execution (Step 4) is deterministic, never AI's domain. Approval (Step 5) is judgment, human's domain. The chain is recorded so audit can verify every step independently.

8. Specifications — what already exists, what is missing

The vision the SSOT describes — interchangeable, ecosystem-accepted specifications for every interface — is partly already built and partly missing. The honest map:

The four "missing" lines are where new standards work would have to land for the architecture to fully deliver. UAPF — or an equivalent format with the same shape — fills the process artifact row. A registry protocol (HTTPS-based, signed, content-addressed) fills the distribution row. The rest is essentially repackaging existing taxonomies and rule expressions into the UAPF shape, by the authorities themselves over time.

The whole architecture works now for a single jurisdiction even if only the first vendor's rule packs exist — Sledger could ship with rule packs for Latvia authored by Sledger, signed by Sledger's authority key. The standardisation conversation with VID and Valsts Kase is downstream of demonstration: build it, run it, then propose it.

9. Non-functional requirements

Beyond the modules and data flows, the architecture has eight cross-cutting requirements that have to be designed in from the start. They do not change the architectural commitments above; they constrain how the modules are deployed.

The most architecturally significant of these is the personal-data vault pattern. Without it, GDPR right-to-erasure conflicts with the immutable audit chain — you cannot delete past data without breaking hash-chain integrity. With it, personal data lives in a separate, mutable store referenced by opaque ID; the events are immutable, the personal data is erasable, and the chain stays intact.

10. The Latvia bootstrap scenario, end to end

This walk-through shows the design under load, with concrete Latvian authorities.

Initial setup — day one.
1. Tenant onboards. Selects Latvia as primary jurisdiction; declares entity type (SIA), business activities, fiscal year. Chooses deployment region (in-country or EU).
2. Sledger fetches the Latvia rule-pack bundle from configured registries:
- From VID's registry: tax processes — IIN, VSAOI, UIN, PVN — plus tax-form schemas and EDS submission transports.
- From Valsts Kase's registry: accounting methodology — FG1 through FG6, statutory chart-of-accounts, gada pārskats template.
- From a Sledger-curated registry: any rule pack that authorities have not yet published themselves (with provenance clearly marked as non-authoritative until adopted).
3. Process registry is populated. The system now knows — declaratively, not in code — how to handle every Latvian event type.
4. Tenant connects bank, e-invoice mailbox, payroll source. Events start arriving.

Operating mode.
- Vendor invoice arrives via Peppol → input adapter normalises → evidence vault stores PDF + UBL XML (content-hashed) → AI classifies as "domestic vendor invoice" with 0.97 confidence → process engine runs PVN classification + posting using VID's signed PVN rule pack v2026.1 → produces journal-entry candidate → human reviews proposal with reasoning trace → approves → committed to event store as a journal_entry_committed event with full chain (AI proposal id, rule pack version, intermediate values, approver signature, hash link).
- Month-end PVN deklarācija: process engine runs the FG3 declaration process over the period's events → produces the deklarācija XML → submission adapter sends to VID EDS → confirmation captured back into the event store as a new event.

A regulation changes.
1. VID amends the PVN rate threshold. Drafts new version of the PVN process. Signs and publishes to the VID registry.
2. Sledger polls the registry, sees lv-vid-pvn version 2026.2 with effective date 2026-07-01. Verifies the signature against VID's published key. Runs the regression suite against the previous version's reference cases.
3. From 2026-07-01 onwards, events with effective dates ≥ 2026-07-01 run under v2026.2. Events with earlier effective dates continue to use v2026.1, even if posted later.
4. The audit trail records the version transition. A retrospective reconstruction of the books as of 2026-06-30 uses v2026.1; reconstruction as of 2026-07-15 uses v2026.2.

An audit takes place.
1. External auditor receives scoped credentials: tenant X, fiscal year 2026, read-only.
2. Auditor opens the auditor interface; runs time-travel query as of 2026-12-31; exports the bilance and PZA in both human-readable and SAF-T form.
3. For each material entry, auditor drills into provenance: source document (re-hashed, verified unchanged) → AI proposal (with confidence and reasoning) → rule pack version (signature verified) → intermediate values → human approver → commit signature.
4. Auditor selects a sample of high-value entries; runs process re-execution; confirms outputs match. Anomaly report flags every override and storno; auditor reviews each.
5. Optional: auditor verifies the period's events against the external Merkle anchor (notary, CT log, or chain) — confirming the records existed at the claimed timestamps.
6. Audit report written. Time spent on data verification: hours, not weeks.

The same scenarios in any other jurisdiction. Replace VID with HMRC, Valsts Kase with HM Treasury, and the Latvian rule packs with British ones. The engine code does not change. The rule packs are different files.

11. What this architecture enables

These properties follow directly from the modular separation and the data layer design, not as added features:

• Compliance updates without software releases. Tax-rate change, new disclosure rule, amended depreciation table — all rule-pack downloads. The application does not enter the change-management process for regulatory churn.
• Multi-jurisdictional from day one. Adding Estonia is loading Estonia's rule pack; Sledger is now an LV+EE accounting system.
• True point-in-time reconstruction. Re-run any historical period using the rule versions that were in effect at the time. Built-in, not an after-the-fact engineering project.
• Auditor-grade verification at machine speed. "Did this entity comply with VID rule X version Y in period Z?" is a database query that returns in milliseconds with cryptographic provenance.
• Vendor-portable methodology. A tenant who switches accounting software keeps using the same authority-issued rule packs; the new vendor's runtime executes the same processes. Methodology travels with the books, not with the vendor.
• Genuine multi-runtime ecosystem. The same UAPF rule pack runs in Sledger, in any other conformant accounting system, in an auditor's verification tool, in a regulator's spot-check tool. Implementation drift between vendors disappears.
• AI safety by architecture. AI never executes math that has a legal answer. Every entry carries a reasoning trace tied to deterministic process versions and human approval. AI failure modes are isolated to classification (recoverable) rather than computation (catastrophic).
• Tamper-evident at six independent layers. Hash chain, signatures, content-addressed evidence, append-only constraints, process re-execution, optional external anchoring. Stronger than any current generation of accounting software offers.
• GDPR-compatible immutability. The personal-data vault pattern lets right-to-erasure coexist with an immutable audit chain.

12. Why this cannot be retrofitted onto existing systems

A natural question is whether this architecture can be obtained by adding AI and modern features to an existing accounting system — Horizon, SAP, QuickBooks, NetSuite. The answer is: most of the visible features yes, the architectural commitments no.

What you can do by adding modules to an existing system:

• Document classification and extraction (bolt-on).
• Natural-language copilot UI (bolt-on).
• Anomaly detection (bolt-on).
• Some forecasting and projection (bolt-on).

What you cannot do by retrofitting, regardless of how much AI you add — these require the data model and core code to change:

1. Make rules into data. Existing systems' tax engines, depreciation logic, statutory reporting templates are baked into the codebase. Making them data would require rewriting the core. The rules-as-data commitment is the principal differentiator and cannot be retrofitted — it is the data model.
2. Make every event content-addressed and chain-linked. Existing systems are CRUD-based; rows update in place. Retrofitting an immutable event log under a CRUD application means rewriting every transactional path. In practice nobody does this — they add audit logs alongside, which are not the same as a hash-chained event store.
3. Make the entire history reconstructible at machine speed. Existing systems have audit logs. Reconstructing books as of a specific past date under that date's rules is engineering work in such systems. With an event store plus versioned rule registry, it is a query.
4. Make the trust boundary architectural. AI-proposes / code-computes / human-approves with cryptographic chain requires the data model to track which AI proposed, which rule pack executed, which human signed, all linked. Bolting this onto an existing system gives you parallel logging that nobody trusts as much as the primary record. The new system's primary record is the chain.
5. Make agents first-class operators with cryptographic authorisation. Retrofitting MCP onto an existing ERP gives you an LLM that calls the ERP's RPC API with a service-account credential. Not the same as agents holding scoped, signed authorisation tokens that flow through to the audit trail.
6. Make multi-jurisdictional configuration rather than engineering. Existing systems support each new jurisdiction as a software project. With rule packs, it is a download.
7. Make compliance updates decouple from software releases. Existing systems ship rule changes on the vendor's release cadence. The customer's regulatory clock is bound to the vendor's release clock. Rule packs sever the binding. Retrofitting cannot.

The simple test: pick any of these properties; ask whether the existing system could retrofit it without rewriting the core. For each, the answer is no — the core would have to change. Once the core has to change, you are building from scratch, with the only advantage being an existing customer base. That advantage is real but not decisive: it brings legacy migration burden in exchange.

The honest framing: retrofitting AI onto an existing accounting system yields AI-assisted bookkeeping. Building from scratch on the SSOT yields the next-generation accounting system. Two different products. The AI-assisted-bookkeeping market is being captured today by well-funded, focused, fast new entrants. The next-generation-accounting-system market — defined by the architectural commitments above — has no occupants anywhere. The architecture is what stakes the second claim.

13. What this document is not

This Reference describes the modules and the data flows. It does not specify:

• The technology stack of any particular module (database engine, programming language, deployment model — though some technology direction is given in the data layer descriptions where it materially affects the architecture)
• The exact UAPF schema (a separate specification document)
• The registry protocol details (a separate specification document)
• The user-interface design or operator workflows
• The particular AI models, prompts, or fine-tuning approaches

Those belong in implementation-level documents that follow from this Reference, the same way this Reference follows from the SSOT.

Editorial notes

Changes since v0.1.

• Module map (§2) expanded to twelve modules with the Auditor Interface added explicitly.
• New §3 The data layer in detail with the five physical data stores spelled out, including the field-level schema for the Event Store.
• New §4 Tamper-evidence model describing the six independent layers of cryptographic guarantee.
• New §5 The Auditor Interface as its own section with the seven auditor capabilities.
• New §9 Non-functional requirements covering the eight cross-cutting concerns identified during v0.1 review (encryption, residency, isolation, GDPR-erasure, DR, observability, AI versioning, plus auditor verification tooling now in §5).
• §10 Latvia bootstrap scenario gained a fourth phase — what an audit looks like end-to-end against this architecture.
• §11 What this enables gained two properties (six-layer tamper-evidence and GDPR-compatible immutability).
• New §12 Why this cannot be retrofitted onto existing systems with seven properties that require core rewrite, not bolt-on.
• Section numbering shifted accordingly. Editorial notes updated.

The core architectural commitment remains that rules are data loaded by the system, not code shipped with the system. Everything else in the document follows from that. If this commitment is wrong, the rest of the architecture needs rework. Worth pressure-testing first.

Open questions for v0.3.
- Pull vs push registry model (or both).
- Conflict handling between overlapping rule packs (e.g., two jurisdictions both claiming a cross-border employee).
- Trust hierarchy between authorities — straight signature verification, or a more elaborate chain-of-trust.
- Where tenant-specific policy authoring lives — inside the rule registry, or a separate tenant-policy module.
- Personal-data vault (§9) — separate top-level module, or a property of the Evidence Vault?
- AI model lifecycle — re-runnability of past inferences if a model has been retired or replaced; cost/latency tradeoff of keeping retired models available.

Sections most likely to need iteration. §3 (data layer), §6 (rule lifecycle), and §10 (Latvia bootstrap) tend to absorb detail as concrete implementation work uncovers it. §1, §2, §11, and §12 are more stable.