Frame the review around a business decision
Begin with a specific decision or workflow the architecture must support. Name the user, the evidence they need and the consequence of a wrong or late result. Define the initial scope and the conditions that would justify expansion.
Ask the team to walk through one representative case from source observation to user action. Record each dependency encountered along the way. This walkthrough establishes a shared frame for the rest of the review and reveals whether key assumptions are business decisions, technical constraints or unresolved questions. Assign an owner to each unresolved question before discussing implementation detail.
Review identity, meaning and time together
Identify the authoritative source for each important entity and explain how identifiers are reconciled across systems. Inspect the definition of business terms used in the decision, including units, status meanings and relationship grain. A technically valid join can still be wrong if one source describes a legal entity and another describes a delivery location.
Review the temporal model as well. Which timestamps represent occurrence, source persistence and ingestion? Can the architecture reconstruct historical conditions after a correction? Ask for an example involving a late event or changed mapping. W3C RDF and PROV provide useful concepts for identity and derivation, but the review must verify how those concepts are applied to the actual information path.
Follow the trust boundaries
Trace the principal and authorization decision through every service, source and derived store. Determine whether a connection uses a user identity or a shared service identity, and how that choice changes effective access. Review secrets handling, restricted logging and permission revocation. Include caches, search indexes and generated answers where they can expose information outside the source interface.
NIST’s zero trust architecture guidance focuses attention on users, assets and resources rather than assuming trust from network location alone. Apply that reasoning to each boundary in the design. Ask what evidence grants access, where policy is enforced and how denial behaves. A component’s location inside a corporate network should not be the entire explanation for its authority.
Rehearse failure before discussing scale
Choose realistic failure scenarios: a source stops responding, a message is duplicated, an extract is incomplete or a workflow times out after the target accepts a request. Ask the team to describe the visible user state, operator signal and recovery steps. Identify any point where the system cannot distinguish failure from an uncertain outcome.
Review retained evidence and recovery boundaries. Determine which operations can be retried, which require reconciliation and which may have irreversible business effects. Examine how a replay affects external actions. Specify how operators will verify data and workflow state after service resumes.
Evaluate representative workloads and constraints
Define the workload in terms of concurrency, data volume, query shape, update frequency and acceptable result age. Inspect source impact as well as application latency. For federated access, verify where filters and joins execute. For persisted products, assess refresh behavior and the state exposed during failure. Test representative queries and data volumes before drawing conclusions about performance.
Consider operating cost and maintainability alongside speed. Identify components that require specialised expertise, manual recovery or duplicated policy management. Record assumptions about source capabilities and external service limits. A design that performs well under one condition may become inappropriate when a business unit, source system or access requirement changes.
Leave with decisions and verification work
Document the chosen approach, alternatives considered, supporting evidence and conditions that would trigger reconsideration. Separate accepted risks from unanswered questions. Assign the tests needed to validate important assumptions, such as compatibility checks, permission matrices, representative load tests and recovery exercises. Each action should have an owner and an observable completion criterion.
Use the review record during implementation and revisit it when evidence contradicts an assumption. Keep it concise enough for a new engineer to understand the architecture’s boundaries. Close verification work against recorded evidence and keep unresolved decisions visible to the people responsible for them.