Dream Consistency Platform Architecture
Shared Realm, Management, and Billing contracts with physically isolated product databases
and product-specific Tenant data.
Dream Consistency standardizes the semantics, migration rules, UUID conventions, and
operational contracts that are genuinely shared between Hestino, Legislator, and future
products. It does not centralize their physical runtime databases.
Core principle:
Shared contract means a shared semantic and migration standard—not one shared production database.
DreamConsistency.RealmTables
DreamConsistency.ManagementTables
DreamConsistency.BillingTables
Product-specific TenantTables
Shared semantics and versioning
+
Separate physical databases per product instance and environment
Hestino and Legislator use the same horizontal Realm, Management, and Billing contracts.
Each product instance still owns separate physical Realm, Management, Billing, and Tenant databases,
credentials, backups, release cadence, and failure domain.
| Layer |
Main Question |
Source of Truth |
| Realm |
What is currently valid? |
Tenant identity, application enrollment, subscriptions, plans, entitlements,
markets, environments, Realms, and current control/commercial state.
|
| Management |
What is executing or what has executed? |
Operations, jobs, steps, retries, package installation state, imports,
usage snapshots, and management audit.
|
| Billing |
What has been calculated, invoiced, paid, or corrected? |
Invoices, invoice items, payments, credit notes, billing runs,
provider references, and immutable commercial/tax snapshots.
|
| Tenant |
What business data does the customer actually use? |
Product-specific data such as Hestino brands, locations, menus, and items,
or Legislator cases, clients, documents, tasks, and time entries.
|
Decision rule:
If data describes agreed or current control state, it belongs to Realm.
If it describes execution, retry, deployment history, or management audit, it belongs to Management.
If it is a financial document or transaction, it belongs to Billing.
If it is customer-facing product business content, it belongs to the product Tenant database.
| Example |
Owner |
| Tenant legal identity |
Realm |
| TenantApplication operational status |
Realm |
| Subscription plan, version, status, and agreed price |
Realm |
| Provisioning operation and persisted steps |
Management |
| Installed product package version per TenantApplication |
Management |
| Invoice, line item, tax snapshot, and payment |
Billing |
| Hestino Brand / Location / Menu |
Hestino Tenant |
| Legislator Case / Client / Document |
Legislator Tenant |
HESTINO PRODUCT INSTANCE
├── Hestino Realm DB
├── Hestino Management DB
├── Hestino Billing DB
└── Hestino Tenant DB(s)
LEGISLATOR PRODUCT INSTANCE
├── Legislator Realm DB
├── Legislator Management DB
├── Legislator Billing DB
└── Legislator Tenant DB(s)
Same horizontal contracts
Different physical databases, credentials, backups, and failure domains
The databases may initially run on the same MariaDB server, but they remain separate schemas
with explicit ownership and credentials. Environment and product boundaries are deployment
configuration, not operator-selected values inside the product Management UI.
| Inside One Database |
Across Physical Databases |
| Database-local GUID RefID primary keys and foreign keys. |
Stable UUID external references; no cross-database foreign keys. |
| Normal referential integrity and local unique constraints. |
API/service validation, idempotency, reconciliation, and explicit lifecycle commands. |
| One ACID transaction where appropriate. |
Orchestrated operations and eventual consistency; no distributed transaction assumption. |
| Local cascade and soft-delete policy. |
No cross-store cascade; historical references remain stable. |
Reference rule:
Internal RefID values never cross database boundaries. Stable UUID values do.
Shared system catalog packages populate the physical Realm, Management, and Billing platform databases.
Product packages populate or configure product and tenant behavior. The two package categories use
different installers, ownership, lifecycle, and user interface.
| Category |
Examples |
Owner / Installer |
| Shared system catalogs |
Realm.Foundation, Management operation statuses, Billing invoice/payment statuses. |
DreamConsistency.SystemCatalogInstaller.Cnsl |
| Runtime / registry state |
Self Realm, tenants, subscriptions, service instances, application versions. |
Dedicated bootstrap, provisioning, or runtime service. |
| Product catalog packages |
Hestino allergens and defaults; Legislator legal catalogs and role sets. |
Product Management package registry and deployment workflow. |
| Customer data imports |
Menus, customer records, CSV/Excel/JSON business imports. |
Product Management import workflow. |
Do not design databases from the sidebar:
A Management screen may aggregate Realm, Management, Billing, and Tenant summaries through
the product Management API. The UI module is not the database ownership boundary.
The Catalog Packages screen in Hestino or Legislator Management refers to product packages deployed
per TenantApplication. It is not the installation interface for shared Realm, Management, or Billing
system catalogs.
| Context |
Identity Source |
Authorization |
| Customer product application |
Local customer Realm account. |
Tenant membership and product role/permission. |
| Hestino.Management / Legislator.Management |
Dream Consistency internal Core identity. |
Internal operator role and product scope. |
| Future DreamConsistency.Management to product API |
Service identity, signed token, or mTLS. |
Allowed caller and versioned product capability. |
| Public Hestino.App |
Anonymous public context. |
Published read model only. |
| Decision |
Status |
| Realm, Management, and Billing are reusable horizontal contracts. |
Locked |
| Each product and environment uses separate physical databases. |
Locked |
| No cross-database foreign keys. |
Locked |
| Product Tenant models remain product-specific. |
Locked |
| Management owns operational history; Realm owns current control state. |
Locked |
| Billing owns immutable financial documents and transactions. |
Locked |
| Future central orchestration uses product APIs, not direct product database access. |
Locked |
| Date |
Change |
Author |
| 2026-07-25 |
Realm, Management, Billing, and Tenant ownership architecture version 3.0 approved as the shared direction. |
Branko |
| 2026-08-01 |
Converted the architecture into the Dream Consistency Wiki structure and linked it to system catalog provisioning. |
Branko |