The full visual model · scripted fictional walkthrough
See the enterprise through its context.
Explore how a mixed legacy and modern estate could be understood, modelled and incrementally supported by suitable technology. Click systems and concepts to inspect the discovery questions and relationships.
AN ILLUSTRATIVE ENTERPRISE · EXPLORE THE TRANSITION
From disconnected systems
to contextual, accountable work.
The walkthrough connects six stages: understand the mixed estate; apply the Contextual Discovery Lens; build an evidence-linked contextual and semantic model; compare suitable technology; deliver separately authorised increments; measure and maintain context for future change.
The enterprise includes a mainframe, ERP, CRM, batch integration, SaaS, APIs, data stores, documents, identity and people. AI assistance never grants itself authority. Read the complete architecture in text.
Understand the enterprise
01 Your enterprise
Legacy + modern + human
02 Contextual Discovery Lens
- Intent & outcomes
- Work & dependencies
- Meaning & evidence
- People & authority
- Readiness & constraints
Sources inform. People validate.
03 Contextual model
Semantic concepts + relationships
Classification · freshness · review status
05 Accountable delivery
- AI or workflow proposes
- People review within authority
- Deterministic controls check
- Authoritative systems commit
- Evidence and recovery follow
A separate implementation and approval scope.
06 Measure · reuse · evolve
Business outcome · quality · risk · operating cost · recovery
Maintain shared context. Reassess new technology. Expand only when evidence supports it.
Lower transformation effort is a hypothesis to test.
From the estate to an accountable transition
The animation above illustrates a proposed process, not an automated transformation engine. Playback is optional. Use manual stage buttons, previous/next and restart; reduced-motion preferences disable motion effects. All components and relationships are fictional. Nothing connects to a customer system or sends data to an AI provider.
What the contextual model contains
The model links outcomes, workflows, activities, roles, systems, information, concepts, policies, authority, decisions, actions, evidence and measures. Each entity has an owner, classification, review status and source references. Relationships also have evidence and review status; an inferred relationship cannot silently become a customer fact.
This is a proposed engagement schema, not a canonical CAE ontology. An ontology provides formal concepts and relationships when the use case needs them. The contextual model additionally needs provenance, permitted purpose, operational state, validity and human stewardship. A graph alone cannot establish truth or grant authority.
| Relationship | Why it matters | Required validation |
|---|---|---|
| Outcome guides Workflow; Outcome measured by Measure | Connect a change to intended value and a testable baseline. | Sponsor and process owner agree definitions and measure source. |
| Workflow uses System; Workflow governed by Policy | Keep implementation tied to actual work and applicable rules. | System owner validates interfaces; policy owner validates version and applicability. |
| Information represented in System; Information supported by Evidence | Distinguish records, meaning and the source of a claim. | Data owner confirms precedence, lineage, permissions and freshness. |
| Authority granted to Role; Authority constrains Action | Separate technical capability from permitted effect. | Authorised client owner grants narrow scope, conditions and expiry. |
| Decision cites Evidence; Decision authorises Action | Make the proposed effect and decision evidence reviewable. | Reviewer confirms exact action and version; backend enforces the accepted scope. |
| Evidence records Action; Evidence informs Measure | Connect execution to review and measured learning. | Service owner checks completeness, retention, access and interpretation. |
A model needs checks beyond its file format
The downloadable schema defines a proposed file structure. A production implementation would also need to validate unique identifiers, relationship targets and types, source access, time validity, policy conflicts, tenant scope and version compatibility. Schema validity alone does not establish semantic correctness, authorisation or safe execution. Those runtime controls are not implemented by this informational release.
The fictional animation fixture is intentionally separate from the schema and from application logic. It demonstrates discovery questions and concepts; it is not a customer-model export or an executable configuration.
The complete synthetic model instance demonstrates all thirteen proposed entity categories, evidence references, ownership and fourteen relationships. Disputed meaning and missing baseline evidence remain explicit. It grants no real authority and cannot execute an action.
The proposed ontology vocabulary in Turtle defines classes and selected relationship domains and ranges for technical review. RDF domain and range declarations support inference; they are not closed-world validation or access-control rules. The JSON model retains relationship evidence and review status; production RDF provenance and validation remain separate design work.
Reuse maintained context for future change
If definitions, evidence and responsibility are maintained, later initiatives can begin with better information. The hypothesis is reduced repeated discovery and integration effort. Measure that benefit against a baseline and include stewardship costs. Do not assume every organisation needs a knowledge graph, an ontology project or an agent platform to improve one workflow.
Explore the capability architecture and cloud comparison or first discovery engagement. Download the static diagram for an accessible discussion aid.
YOUR ENTERPRISE. YOUR NEXT CHAPTER.
Turn complexity into
a clear next move.
Bring a business question. We can discuss a discovery scope and the decisions it should support.
Start a discovery conversation