Multi-Realm architecture, regional product control planes, self-hosted federation, CentralManagement direction, and the shared Dream Consistency Billing domain.
| Decision | ACTIVE MASTER DIRECTION |
| Immediate delivery target | Hestino Billing V1 |
| Shared direction | Reusable product-neutral Billing for Hestino, Legislator and future products. |
| Central management | Federated control plane; never direct database access. |
A Realm represents an independently deployed product environment with its own data, runtime configuration, service identities, secrets and operational lifecycle.
A Realm belongs to a product. Hestino and Legislator therefore operate in separate Realms.
Hestino is a Dream Consistency-hosted product and does not currently support customer self-hosting.
Additional Hestino regional Realms may be introduced when geographic, regulatory, availability, or scaling requirements justify them.
Legislator supports both Dream Consistency-hosted and customer self-hosted deployments.
A self-hosted law firm is treated as an independent Legislator Realm, but its commercial and fleet relationship remains attached to the relevant Dream Consistency-operated regional Legislator domain.
Self-hosted Legislator installations keep their own local operational Realm state and remain capable of operating independently according to the supported offline/ disconnected policy.
Ordinary self-hosted installations do not host Dream Consistency's vendor financial ledger. Billing for the commercial relationship between Dream Consistency and the law firm remains in the relevant Dream Consistency-controlled regional Legislator domain.
Self-hosted customer environments should not require inbound Internet access from Dream Consistency control systems.
The preferred direction is a secure customer-initiated outbound communication model between the self-hosted Realm agent and the appropriate regional Legislator agent/control plane.
The exact transport is intentionally not locked by this decision. The federation contract should remain transport-neutral.
CentralManagement is the future global fleet and business control plane for Dream Consistency products and Realms.
Cross-Realm information is obtained through versioned product/Realm contracts and aggregated by CentralManagement.
DreamConsistency.Billing is the product-neutral financial domain.
Hestino is the first consumer, but Hestino-specific concepts must not become part
of the reusable Billing core when a generic financial concept is sufficient.
| Domain | Canonical Ownership |
|---|---|
| Realm | Current subscription, plan, version, price, add-on, entitlement and commercial truth. |
| Billing | Durable invoices, item snapshots, party snapshots, payments, allocations, refunds, credit notes, BillingRuns and financial audit history. |
| Management | Product control plane, commercial commands and integration/composition surfaces. |
| Tenant/Product DB | Product operational data; never the Dream Consistency financial ledger. |
Billing Client communication follows the standard Dream Consistency Service-to-Service Communication architecture.
The Billing API must not depend on its Client package.
The immediate implementation goal is Hestino Billing V1. Future multi-product architecture must not cause premature implementation of features Hestino does not yet require.
Hestino Billing should ultimately support:
Billing must not independently reconstruct or edit current commercial truth.
For Hestino, the target architecture is an explicit versioned commercial source contract exposed through the Hestino product control plane.
Billing receives authoritative billable commercial inputs and freezes the relevant financial values into Billing-owned historical records.
The following capabilities are expected future extensions but are not required to be implemented before the core Hestino Billing model is correct.
Provider-specific integrations remain adapters around the canonical Billing domain. No external provider model becomes the Billing core data model.
External delivery and financial automation must not be implemented as one long synchronous HTTP request.
Each step must be idempotent, retry-safe, auditable and recoverable after process restart.
| Date | Change | Author |
|---|---|---|
| 2026-09-30 | Established Master architecture direction for Realm federation, Legislator self-hosted hierarchy, CentralManagement and the shared Billing domain. | Branko |