Skip to content

Last reviewed: 2026-08-02

Kernel Contract

Purpose

The BooksPlus kernel is the set of accounting, period, posting, evidence, audit, and authority behaviors that must be implemented once and reused consistently.

The kernel is not a catch-all package. It is a collection of canonical responsibilities owned by the appropriate domain areas and exposed through explicit contracts.

Kernel responsibilities

Kernel-level behavior includes:

  • company identity and context for company-scoped accounting, security, audit, backup, and reporting behavior;
  • financial period identity, boundaries, hierarchy, and status;
  • company accounting time-zone identity and shared business-date cutoff resolution;
  • centralized period control for posting, close, and reopen;
  • centralized posting and posting policy enforcement;
  • centralized correction posting modes and immutable direct target relationships for reversal and adjustment;
  • source-document and evidence linkage where policy requires support;
  • append-only audit events for consequential actions;
  • authorization for protected accounting and administrative actions;
  • small shared primitives such as money, dates, identifiers, and result codes.

Kernel boundary rule

A behavior belongs in the kernel when all of these are true:

  • multiple BooksPlus workflows depend on it;
  • inconsistent implementation would damage accounting truth, auditability, or user trust;
  • duplicating the behavior would create policy drift;
  • the behavior expresses durable BooksPlus meaning rather than one screen, report, or workflow convenience.

Ownership

Kernel responsibilities stay with the domain area that owns the business meaning.

Responsibility Canonical owner
Company identity and company context Company
Named-zone validation and business-date cutoff resolution Shared primitives
Financial period definition and identity Financial periods
Period state transitions, close, reopen, waivers, and approvals Close
Journal posting and posting policy enforcement Accounting
Standard report definitions, execution, snapshots, currentness, and drilldown Reporting
Source document identity, evidence references, and supersession Source documents
Append-only audit events and artifact verification Audit
Protected actions, role permissions, and step-up confirmation Security
Money, date ranges, identifiers, and narrow shared contracts Shared primitives

Rules

  • Posting-capable workflows must use the central posting contract rather than writing ledger effects directly.
  • Cross-workflow corrections use the Accounting Correction Contract and central Accounting rather than mutating their owning workflow or posted result.
  • Company-scoped workflows must resolve company context before changing accounting records, permissions, audit records, backups, or sensitive company data.
  • Posting must evaluate the target financial period through central period control.
  • Timestamp-based period selection must use the company accounting time zone and shared Business Time Contract.
  • Close may coordinate accounting work, but close must not mutate ledger truth outside the central posting path.
  • Close consumes persisted formal reports through the Reporting-owned resolver and must not reconstruct report values or currentness.
  • Soft close, hard close, waiver, approval, and reopen must use the Close Run Contract; generic financial-period status mutation is only a low-level implementation seam.
  • Source evidence must be linked durably when policy requires support.
  • Consequential actions must emit attributable audit events.
  • Protected actions must enforce authorization using business meaning, not only generic create, read, update, and delete permissions.
  • Shared primitives must stay narrow and must not absorb feature-specific workflow logic.

Non-kernel behavior

The following behavior does not belong in the kernel unless promoted by an explicit accepted decision:

  • individual screen flow;
  • report layout;
  • inventory costing method details;
  • import file parsing;
  • feature-specific defaulting;
  • local workflow status labels that do not affect accounting truth;
  • persistence, UI, or framework wiring.

Developer implications

  • Keep domain rules independent of Avalonia views, view models, persistence models, and platform services.
  • Use application-level commands, queries, or services to coordinate kernel contracts.
  • Keep infrastructure adapters behind domain or application contracts.
  • Test kernel behavior as durable business behavior, not only as UI behavior.
  • ../accounting/financial-periods.md
  • company.contract.md
  • business-time.contract.md
  • ../accounting/posting-and-reversal.md
  • accounting-correction.contract.md
  • close-run.contract.md
  • reporting.contract.md
  • ../accounting/close.md
  • ../accounting/reporting.md
  • ../accounting/source-documents.md
  • security/protected-action-contract.md
  • security/audit-event-contract.md