- Home
- Architecture
Architecture
Four planes, one canonical model, one release pipeline.
Written for CIOs, architects, security teams and implementation partners. The Platform page explains the same system in business terms; this one does not simplify.
The four planes
What sits where.
Products
Six finished applications, each owning its own domain logic and interface. Products hold their own detail but never their own copy of a canonical record.
Canonical model, identity, permissions, events
The shared substrate. One organisation, customer, employee, agreement, invoice and entity. One identity and permission model. One event stream that every application publishes to and subscribes from.
ProcessScout
Consumes semantic telemetry and application events, correlates them with contextual user feedback, and produces sized, evidenced requirements. It reads the operating plane; it does not become a second source of truth.
Change and release control
Requirement linkage, test gates, review, approval routing, per-tenant feature gates, release monitoring and rollback. Every material change to any plane passes through here.
Canonical data model
One record, many views.
The canonical model is deliberately small. It holds the entities that more than one application legitimately needs, and nothing else. Everything specific to a domain stays in that domain.
This is why integration inside BetterWrk is not the same problem as integration between SaaS products. There is no synchronisation, because there is no second copy to synchronise.
- Organisation
- Legal entities, operating units, hierarchy and inter-entity relationships.
- Party
- Customers, suppliers and contacts, with role-based relationships to entities.
- Person
- Employees and workers, with assignment, role and reporting relationships over time.
- Agreement
- Contracts, offers and their commercial terms as structured data, not as an attachment.
- Work
- Delivery cases, sequences, milestones and effort.
- Financial
- Invoices, payments, cost postings and ledger references.
Event model
Facts, published once.
Applications publish domain events describing things that happened — agreement executed, employee started, invoice issued, milestone completed. Consumers subscribe. Nothing polls another application’s database, and nothing screen-scrapes.
- Events are versioned and backwards-compatible within a major version
- Delivery is at-least-once; consumers are idempotent
- Every event carries tenant, actor, correlation and causation identifiers
- The audit log is derived from the same stream, so audit and behaviour cannot diverge
- Customer-accessible event subscriptions are available for systems you keep
Extension model
Where customer-specific work lives.
Customer-specific capability is not a fork. It is built in the product codebase, isolated by tenant-scoped feature gates, and subject to the same pipeline as everything else.
- Configuration — tenant data, no code path change
- Extension points — defined hooks with a supported contract
- Gated capability — product code, released to named tenants only
- Promotion — a gated capability can become general, with your agreement, if it is genuinely useful to others
- No customer runs a private fork that stops receiving platform updates
Release pipeline
From requirement to production.
Requirement
Evidence from ProcessScout or the Fit Blueprint becomes a stated requirement with an acceptance measure.
Build and test
Change linked to the requirement. Unit, integration and regression suites, security and dependency scanning, plus validation against historical cases where they exist.
Review
Human review by someone who did not write the change. Sensitive domains carry additional reviewer requirements.
Approval
Routed to the named customer approver where the change touches payroll, finance, permissions or contract logic.
Gated release
Enabled per tenant behind a feature gate. Scope is explicit and recorded.
Monitor and measure
The acceptance measure is tracked after release. Rollback is a gate change, not a deployment.
Observability and deployment
How it runs.
- Observability
- Structured logging, metrics and distributed tracing across applications, correlated by the same identifiers as the event stream.
- Managed runtime
- The default deployment. BetterWrk operates, patches and monitors the environment and holds the availability commitment.
- Customer cloud
- Deployment into your cloud account where residency, network or regulatory requirements demand it. Support boundaries are defined in writing.
- Self-hosting
- Available under Buy + Assure for qualifying customers. Some regulated modules carry stated limitations.
- Environments
- Separate non-production environments for acceptance testing, with masked or synthetic data.
- Continuity
- Data and configuration export throughout, source-code escrow options, and a qualifying fallback operating right under Buy + Assure.
Get the full technical pack.
Architecture documentation, data-flow descriptions, the event catalogue, the software bill of materials and our security position, under NDA.