Reviewing a Multi-Domain Internal Platform

A broad internal platform may combine identity, requests, approvals, records, purchasing, inventory, support and resource booking. Reviewing each screen separately misses the shared decisions that determine whether the whole platform is coherent. Reviewing only the shared framework misses the awkward physical and organisational rules inside each domain.

Start with platform-wide invariants

Write the rules that every domain must obey: scope boundaries, authentication, authorization, audit-event shape, file handling, approval separation and error semantics. Then trace each invariant to its enforcement point. A principle in an architecture document is not a control until a request path cannot bypass it.

• Every row-producing query applies the caller's scope before pagination and aggregation.
• Every consequential action records the actor, reason and resulting state.
• Approval cannot be completed by the same identity that initiated the controlled action.
• Files pass through the same authorization and lifecycle rules as their parent records.
• Exports have explicit authority and schemas rather than inheriting ordinary view access.

Review the seams between domains

The highest-risk defects often sit where one domain hands work to another: an approved request becoming a purchase, a receipt becoming stock, a support case attaching a restricted document, or a role change affecting existing assignments. Check which facts are copied, which remain referenced and what happens when either side changes later.

A shared vocabulary helps, but identical labels can hide different semantics. 'Approved' may mean authority to order in one workflow and final acceptance in another. Review state transitions in their business context rather than assuming a common enum proves a common meaning.

Use tests and review for different questions

Tests are strong at preserving understood behaviour. They can prove that an expired grant is rejected, a reservation cannot overdraw stock, or a restricted field is omitted. They are weak at finding a permission the model forgot to define or a business distinction that both code and tests collapse.

Adversarial review asks where the model is incomplete: what can be inferred without opening a record, which actor combinations defeat separation of duties, which approval-time facts can go stale and which apparent control has no enforcement point. Findings should be numbered, assigned and closed with evidence rather than disappearing into an informal conversation.

Review failure paths as product behaviour

A platform is defined as much by refusals and recovery as by successful transitions. Simulate duplicate submissions, partial imports, conflicting approvals, missing external inputs, unavailable files and concurrent edits. The response should preserve integrity and tell the user what can happen next without revealing protected context.

Build a review matrix before reading implementation details

Create a matrix with domains on one axis and cross-cutting concerns on the other. Useful columns include identity, scope, authorization, audit, files, exports, concurrency, retention, notifications, recovery and observability. Each cell should name the relevant promise, enforcement point, verification method and current evidence. Empty cells are valuable: they reveal decisions the platform has not made rather than merely code the reviewer has not found.

For a synthetic example, imagine a request workflow that creates a purchasing action, which later produces a stock receipt and a support attachment. The matrix forces separate questions. Can an approver see only requests in scope? Does the purchase retain the approved quantity or read a mutable request later? Can the attachment be downloaded by someone who can view the support case but not the underlying request? Does deleting a user preserve their audit identity? The workflow looks complete on screen while each seam can still violate a different invariant.

Review authorization as data flow

Do not review permissions only as route guards. Trace protected attributes from query to serializer, count, search index, export, cache key, notification and audit event. A field omitted from the interface can still leak through an aggregate or background message. Apply scope before pagination and aggregation, and verify that cache entries cannot be reused across callers with different visibility.

Construct a compact actor matrix using synthetic identities: ordinary user, delegated approver, records administrator, support operator and platform administrator. For each sensitive transition, test allowed, denied and cross-scope cases. Then test combined roles. The dangerous case is often not a missing permission but two individually reasonable roles that together bypass separation or expose a broader query path.

Check state machines for stale decisions

Approval-time facts can change before execution. A request may be edited, a grant may expire, a resource may become unavailable or a file may be replaced. Decide whether approval freezes a version, whether execution revalidates current facts, or whether both are required. Store the version reviewed so the platform can explain what the checker approved. Reject silent execution against materially different data.

Review asynchronous effects end to end

A queued message is not a delivered effect. Trace each durable instruction from transaction to outbox, worker, external adapter, retry policy, dead-letter handling and operator alert. Test the awkward boundaries: the transaction commits but the worker crashes; the external endpoint succeeds but the acknowledgement is lost; a retry arrives after an operator cancels the work. Idempotency and reconciliation are product requirements, not queue configuration details.

Include performance and degradation in the review

Performance failures can become integrity failures when users retry, abandon a partial operation or work around the platform. Define budgets for common reads, consequential writes, search and exports using synthetic datasets with realistic shape rather than sensitive records. Inspect query counts, index use, pagination stability and lock scope. Test how the platform behaves when search, storage or messaging is slow: protected writes should not become ambiguous merely because a secondary service is unavailable.

Exercise backup, restore and reconciliation

A backup success notification is not a recovery test. Restore into an isolated environment, verify schema and object-store alignment, re-run invariant checks and confirm that queued work does not accidentally execute. Define the acceptable loss window and recovery time for each domain. A booking calendar and a financial approval queue may need different recovery objectives even when they share one platform.

Phase the review by risk, not screen count

1. Map domains, data classes, actors, trust boundaries and platform-wide invariants.
2. Review identity, scope, files, exports and administrative paths before ordinary happy paths.
3. Trace the highest-consequence state transitions and cross-domain handoffs with synthetic scenarios.
4. Exercise concurrency, retries, degraded dependencies, restore and operational reconciliation.
5. Close findings with reproducible evidence, then run a focused regression pass over every shared invariant affected by remediation.

The trade-off is breadth versus depth. A complete matrix can become ceremonial if every cell receives equal attention. Rank domains by consequence, exposure and change rate, then sample lower-risk areas while exhaustively tracing the shared controls that can fail everywhere. State the sampling boundary so absence of a finding is not misreported as exhaustive assurance.

Separate software completion from organisational readiness

Built and tested is not the same as adopted and controlled in operation. Cutover needs named owners, reconciled parallel runs where appropriate, support procedures, access administration, training and explicit acceptance. Track those as operational claims instead of converting a passing build into a deployment claim.

Keep review evidence reproducible

• Record the requirement or invariant being tested.
• Identify the request path and enforcement point examined.
• Preserve the failing scenario without copying sensitive production data.
• Link the correction to a regression test or other repeatable check.
• State what was not verified, including unavailable environments or integrations.
• Record dataset shape and tool versions needed to reproduce performance evidence.
• Attach restore and reconciliation evidence rather than relying on backup status alone.

The aim is not a large finding count. It is a platform whose shared controls are consistent, whose domain exceptions are explicit and whose readiness claims do not outrun the evidence behind them.