Connected applications
Blueprint lets a product describe shared business meaning across application boundaries. The useful starting point is a connected domain: people perform work, work follows governed information, and outcomes retain evidence.
The example below is a proposed composition, not a bundled suite or a claim of finished integrations. Each application needs declarations, bindings, access rules, and verified runtime journeys.
One input, two connected outputs
Shared services enforce the contract. Applications present and use it through appropriate workflows. A shared model does not automatically give every user access to every connected record: grants, policy, and row-level security still apply at each boundary.
Choose the right identity
| Concept | Model choice | Reason |
|---|---|---|
| Person | Entity | Independent identity, access, and references |
| Contact details | Facet of Person | One dimension of the same identity |
| Procedure | Governed information entity | Stable identity with immutable versions and revision workflow |
| Qualification | Association entity | Person–procedure connection with validity and evidence |
| Operation plan | Versioned information entity | Intended choices for an objective |
| Operation run | Occurrence entity | Actual actors, times, outputs, and disposition |
| Case | Entity referencing run and evidence | Independent investigation lifecycle and permissions |
A relationship names the graph meaning. A reference field owns the stored foreign key. A rich connection becomes an association entity when it needs its own history, repeated occurrences, validity, permissions, or evidence.
Follow a procedure through the system
- Docs publishes a governed procedure revision. Future execution can pin that exact revision; past runs retain their original pins.
- Qualify records training and qualifications against people and governing information. A qualification has explicit validity and evidence.
- Directory supplies authoritative person and assignment references. Applications use those identities instead of maintaining independent copies.
- Operations plans and executes work. The action runtime evaluates the declared permissions, applicable policy, qualification conditions, and evidence requirements before committing actual outcomes.
- Case Management connects a deviation or exception to the run, its governing information, and retained evidence. Corrective actions have their own declared lifecycle.
Publishing a new procedure does not silently rewrite training or past runs. The product must declare how a revision affects qualification, future plans, and outstanding work. Notifications and external integration use explicit post-commit effects and adapters.
Questions the connected model can answer
With the appropriate declarations, retained records, authorized queries, and bindings, applications can ask:
- Which people are qualified for this procedure revision at this time?
- Which governing revision and policy applied when this operation ran?
- Which plans reference information that has since changed?
- Which exceptions link to this run, and what disposition followed?
- Which runtime decisions and evidence explain why an action was allowed?
These insights come from explicit relationships and provenance. Their availability depends on the product model and query implementation.
Keep the authorities clear
Blueprint declarations and the canonical definition describe the model. Generated SQL, protocol artifacts, and UI metadata are projections. PostgreSQL and the transactional runtime own operational enforcement. Studio owns shared enterprise UX; Blueprint UI translates metadata into Studio contracts.
External ontology mappings improve explanation and interoperability without creating a second mutation authority. Conceptual influences include Palantir's action types, W3C PROV-O, W3C RDF, and W3C OWL. These influences do not imply integration or formal conformance.
Continue with the presentation,