The architecture · proposed CAE interpretation
The contextual lens connects the enterprise.
Technology choices become more useful when they are grounded in the organisation’s meaning, work and authority. Build a contextual model first, then apply suitable automation, AI and agent capabilities around it.
The Contextual Discovery Lens and CAE
Contextual Discovery Lens is the working name for this initiative’s proposed discovery approach and visual model. It is not presented as an established CAE construct, a registered technology or a production software engine. It examines a workflow through business intent, people, process, information, technology, authority and evidence.
The output is a proposed organisation-specific contextual model: a versioned account of concepts, relationships, owners, source evidence and limits. A semantic model makes terms and relationships explicit. An ontology can formalise selected concepts and relationships where that effort supports a concrete use case. Neither requires replacing the systems of record.
The intended value is reusable context: later initiatives can reuse verified definitions, dependencies and authority decisions. Lower future transformation cost and easier delivery are hypotheses to measure, not reported customer outcomes. Applicability, effort and value depend on the organisation, information quality, operating model and approved scope.
- 1 / Business intent and peopleOutcomes, users, sponsors, process owners and service responsibilities set the purpose and decision rights.
- 2 / Context and evidenceBusiness vocabulary, concepts, relationships, source records, provenance, freshness and permitted use provide the contextual model.
- 3 / Reasoning and workflowsAnalytics, fixed automation, model assistance and bounded agent loops are selected for the actual work.
- 4 / Authority and controlsIdentity, policy, scope, human review and deterministic checks constrain the point where a proposal becomes an effect.
- 5 / Systems of recordExisting applications, APIs, integration services and transactional records remain authoritative for business state.
- 6 / Outcomes and feedbackEvaluation, decision evidence, operations, cost and recovery inform whether to continue, revise or stop.
These layers are an original visual explanation of the proposed CAE approach. They are not a claim that selecting a platform supplies the full operating model. Explore the animated model.
Contextual Trust across the architecture
Contextual Trust brings security and trust review across business intent, people, context, reasoning, authority, integrations, infrastructure and operations. These are review views spanning the architecture, not an extra isolated layer. Analysis identifies obligations and gaps; enforcement requires identity, retrieval permissions, policy gates, scoped adapters and operational controls in the actual execution paths. The current introductory assessment does not demonstrate enterprise-wide enforcement.
A capability comparison, not a product equivalence table
Candidate services below are documented by the providers. Their placement into CAE capabilities is our interpretation. None is integrated into this release. Product names and documentation were checked on 1 November 2026; regional availability, release stage, quotas, exact feature support and Australian pricing need checking for the target deployment.
| CAE capability | AWS candidates | Google Cloud candidates | Microsoft Azure candidates | What remains customer-owned |
|---|---|---|---|---|
| Business experience and channels | Existing application and API Gateway | Existing application and Apigee | Existing application and API Management | User research, accessible experience, purpose, channel identity and support. API services do not supply the business experience. |
| Models and model access | Amazon Bedrock | Gemini Enterprise Agent Platform model capabilities | Microsoft Foundry supported models | Model selection, data-processing basis, evaluation, routing, budget and fallback. Catalogues and APIs differ. |
| Agent and workflow orchestration | AgentCore, Step Functions | Agent Platform runtime, Workflows | Foundry Agent Service, Logic Apps | Business state, retries, idempotency, stop conditions and allowed effects. A runtime and a business workflow are different capabilities. |
| Integration and APIs | API Gateway, AgentCore Gateway | Apigee, Workflows | API Management, Logic Apps | Authorised adapters, backend rules, schema, tenant isolation and protection of alternate paths. |
| Data, retrieval and memory | Bedrock Knowledge Bases, AgentCore Memory | Agent Platform context capabilities; retain existing repositories | AI Search and Storage in the reference architecture | Source permissions, freshness, deletion propagation and retrieval evaluation. Memory is not authoritative business state. |
| Semantics, metadata and governance | Glue Data Catalog and Lake Formation | Knowledge Catalog, formerly Dataplex Universal Catalog | Microsoft Purview | Business definitions, ontology stewardship, lineage completeness and dispute resolution. Cataloguing does not create a verified enterprise semantic model. |
| Identity and delegated authority | AgentCore Identity and Gateway Policy | IAM, workload and agent identity options | Foundry identity and security and application permissions | The legal and business mandate, per-action scope, user delegation and revocation. Identity is not business approval. |
| Security, privacy and risk | AWS architectural review plus configured service controls | Google Cloud architectural review plus configured service controls | Landing-zone reference controls plus configured service controls | Threat model, privacy review, tenant boundaries, safe document handling and risk acceptance. No compliance guarantee is inferred. |
| Evaluation, tracing and operations | AgentCore operational capabilities | Agent Platform lifecycle capabilities | Foundry observability and evaluations | Representative test cases, business-quality thresholds, redaction, alert response and outcome evidence. Features differ by service and release stage. |
| Human review and exceptions | Step Functions approval example | Workflows callbacks | Logic Apps workflows with an approval application | Reviewer identity, authority, action binding, expiry, rejection, escalation and safe resumption require implementation. |
| Infrastructure and recovery | AWS Well-Architected plus selected hosting | Google Cloud Well-Architected plus selected hosting | Azure landing-zone architecture plus selected hosting | Recovery objectives, backups, tested restores, dependency resilience and operational skills. Frameworks are review guidance, not deployable products. |
| Cost, constraints and portability | Metered selected services; architecture trade-offs | Metered selected services; architecture trade-offs | Selected service charges and licences; architecture dependencies | Model usage, storage, egress, support, people, retries, test environments and exit cost. No price or performance equivalence is asserted. |
| Business outcomes and evidence | Customer outcome register linked to execution evidence | Customer outcome register linked to execution evidence | Customer outcome register linked to execution evidence | Sponsor, baseline, measure definitions, review cadence, attribution and the decision to expand or stop. No provider supplies the business outcome automatically. |
Choose by constraints and evidence
AWS may fit an existing AWS estate and teams using its workflow and agent services. Assess the assembly of business state, tool policy and human approvals. Google Cloud may fit existing Google data and AI capabilities; its current documentation shows changing product names, so confirm the exact service and API before designing. Azure may fit an existing Microsoft identity and application estate; evaluate its connected service dependencies and licensing rather than assuming existing licences cover everything.
Start with the current stack where it can meet the need. A fixed workflow may be simpler to operate than an agent. Moving data between clouds may add latency, egress cost and governance complexity. Self-hosted or hybrid options can preserve selected boundaries but still need hardware capacity, model licensing, patching, identity, evaluation and support. No unverified open-source implementation is recommended by this release.
A contextual model is a maintained product
Name its owner. Version its concepts and relationships. Record evidence, classification, permitted purpose and validity dates. Keep uncertainty visible. Review changes to business terminology and authority before they affect execution. Verify that deleting source access also removes access from derived retrieval and memory stores.
A reusable model can support later transformation only if it remains current and trustworthy. Measure reuse effort, integration lead time, exception rates and operating cost against a defined baseline before claiming that transformation became cheaper or easier.
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