Own the record, decision, failure and recovery

Turn every loop into an ownership decision

The method says when purpose, design, delivery, operation and assurance need to exchange learning. The blueprint says which logical responsibility sends or receives the information.

A logical component is a named responsibility with an owner, defined interactions and known failure behaviour. It does not have to be a program, microservice or product. One deployment may perform several logical roles, and one role may later be split when scale, security or independent change makes that useful.

Follow one rebooking request across the roles

When an appointment is cancelled, the interaction should be clear before the team chooses software:

1. The domain-record component remains authoritative for the appointment and reports the cancellation with a stable reference.
2. The work component accepts one repeatable rebooking request, creates one work item and records the responsible scheduling role.
3. The identity component supplies the scheduler’s identity, role and delegated authority with each action.
4. The rule component receives defined facts and returns the deadline or priority, the rule version and an explanation.
5. The experience component shows the scheduler the work and sends the accepted result back to the work component.
6. The communications component receives the accepted change and records whether the message was delivered or failed.
7. The operations and audit responsibilities distinguish software health from work state, preserve who acted and help support staff recover without rewriting the history.

This path exposes ownership, requests and results. A deployment diagram can follow once the team understands them.

Name every responsibility a complete service needs

Help people act and own work

• Experience and access presents accessible interactions to participants, staff and support roles through the appropriate channel.
• Authoring and configuration workbench lets authorised people edit, validate, explain and version languages, rules and work definitions.
• Identity, trust and consent supplies the actor, role, delegated authority, consent and policy context.
• Work, case and workflow management owns work items, responsibility, queues, deadlines, escalation, completion and work history. Open BPM is the proposed reference implementation.
• Rules, decisions and policy receives agreed facts and returns a versioned decision, calculation or transformation. cREXX is the preferred first surface for this role where it fits.

Keep facts clear and components connected

• Domain records and information owns authoritative business facts, their provenance and their lifecycle.
• Content and documents owns managed attachments, templates, rendering and retained records.
• Integration and adapters translates between models and isolates an external system from the service’s internal responsibilities.
• Commands, application programming interfaces (APIs) and events define how one component requests a change and how another reports an accepted fact.
• Communications sends notifications and reminders and records delivery, refusal or failure.

Use sources and computational tools without confusing their authority

• Knowledge, retrieval and source grounding reconciles source material, preserves provenance and returns passages, accepted claims, ambiguity, conflicts and gaps to a person or agent.
• AI orchestration and tool execution connects model calls, retrieval, scripts, external processes and human-input steps during one graph execution.
• AI assistance and assurance decides where artificial intelligence is justified, records the model and tools used, evaluates results and escalates consequential decisions to people.

Operate, recover and learn

• Audit and provenance records who or what acted, why, under which authority and using which rule or source.
• Observability, operations and support reports software health, supports diagnosis and assigns recovery responsibility.
• Platform and delivery owns builds, supply chain, configuration, secrets, runtime and deployment.
• Scenario director sets up synthetic data, faults and time for a Public Purpose Lab demonstration. It is never a production business component.

Keep sources, computational steps and durable human work separate

These roles may collaborate in a future service, but they own different things. The knowledge component returns source-backed material and identifies gaps. Cognitive Pipelines currently coordinates computational and AI-assisted steps inside a desktop graph execution. Open BPM is intended to own durable cases and work items over hours or days, including refusal, deadlines, escalation and recovery.

A future orchestration flow could request material from crexx-rag, ask Open BPM to create human work and receive the accepted result later. That composition is a useful design test, not a current integration.

Specify how each component handles disagreement and failure

For every logical component, record:

• The result it owns and what remains elsewhere.
• Its users, operator and human decision rights.
• The requests it accepts and the facts it reports.
• The information it owns, references and retains.
• Its security, privacy, consent and authority rules.
• What happens when a request is repeated, delayed, refused or partly completed.
• How another role observes failure and who may recover the work.
• The qualities a defined check must test.
• Current implementations, alternatives, limitations and next tests.

Use the component responsibility and failure-review assets to apply these questions. Then compare the design with the current working components before selecting an implementation.