Skip to content

Persona Benefits

Substrate provides specific, data-driven value to every member of the software delivery lifecycle. The platform is not a specialist tool used by one role — it is a governance layer that every person who touches the system interacts with differently, and from which every role receives distinct, concrete benefits.

1. Developer

Primary value: Structural confidence without cognitive load.

A developer's job is to build features and fix defects. Substrate's job, from the developer's perspective, is to provide immediate, precise, actionable feedback on structural correctness — without requiring the developer to hold the entire architectural model in their head.

Scenario: PR Violation with Full Causal Chain

Without Substrate: A developer introduces a new direct dependency from the UI layer to the payments database. The violation is invisible to linters and compiles cleanly. It may pass code review if reviewers are not familiar with the relevant architectural constraint. If it is caught, the developer receives a comment saying "you can't do this" with no context for why. If it is not caught, it reaches production where it creates a latency anomaly six weeks later during a high-traffic event. Root cause identification requires three engineers, two days, and access to two years of git history.

With Substrate: The PR is blocked automatically by the CI/CD check. The developer receives: - A plain-English violation message: "This change creates a direct dependency from ui-service to payments-db, violating the three-tier isolation policy." - A link to the ADR that established the constraint: ADR-047: Three-Tier Isolation for PCI Compliance - The causal history: the 2024 incident that prompted the ADR, the post-mortem that formalised it, and the Rego policy that enforces it - A concrete fix suggestion: "Route this call through payments-service instead"

The developer has full context in under 30 seconds. No senior engineer consultation required. No archaeology.

Scenario: Library Import — License Conflict Detection

Without Substrate: A developer adds a new open-source dependency with an AGPL license to a proprietary codebase. The conflict is missed in the review. It surfaces in a legal audit six months later, requiring an emergency remediation sprint.

With Substrate: The substrate/license-compliance policy pack flags the AGPL license on the PR comment before merge. The developer is informed, the policy exception process is triggered if appropriate, or the dependency is replaced with a compatible alternative before any code is shipped.

Scenario: Dependency Query

Without Substrate: The developer needs to understand what a service depends on before making a change. This requires reading source code, checking Terraform files, reviewing the Confluence page (which may be stale), and asking a colleague who worked on the service two years ago.

With Substrate: A natural language query — "what does the auth service depend on?" — returns a live subgraph with all dependency edges, their types, their last-verified timestamps, and links to any relevant ADRs. Response time is under one second. The answer is drawn from the actual current state of the system, not from documentation that may not have been updated since the last major refactoring.

Scenario: "Why Does This Constraint Exist?"

Without Substrate: The developer encounters a confusing architectural constraint — why can't the notification service call the user service directly? There is no obvious answer in the codebase, and the engineer who made the decision has left the company.

With Substrate: The query "why can't the notification service call the user service directly?" returns ADR-031 (the constraint), PM-019 (the post-mortem that triggered it), and IntentAssertion-007 (an informal decision captured from a Slack thread at the time). Full rationale, full provenance, fully queryable.

Scenario: Intent Mismatch Detection

Without Substrate: A developer's PR is titled "Fix null pointer exception in checkout flow" but the diff includes changes to the payment routing logic that were not part of the original ticket scope. This scope creep goes unnoticed until QA.

With Substrate: The Reasoning Service detects that the code change vectors have diverged significantly from the ticket intent embeddings. A PR comment flags the mismatch: "Code changes appear to extend beyond the scope of ticket CHK-447. Affected nodes: payment-router, checkout-service. Confirm scope or update ticket."

2. Tech Lead / Architect

Primary value: Enforcement authority and pre-commitment simulation.

A tech lead or architect is responsible for the structural integrity of the system. Substrate gives them the tools to make that responsibility real — not advisory, but enforced — without becoming a bottleneck in the delivery pipeline.

Scenario: Proposing a Service Split

Without Substrate: The architect sketches a service split on a whiteboard, shares it in a design document, and waits for informal feedback. The team begins implementing. Three weeks in, they discover that the split would require seven API contract changes, affects two teams downstream, and violates the API-gateway-first policy. The discovery costs a sprint.

With Substrate: Before any code is written, the architect describes the proposed split in natural language: "Split the UserService into UserReadService and UserWriteService, with UserReadService handling all query operations." The Simulation Service returns: - Before/after policy comparison: 3 policies would fire on the proposed topology - Blast radius: 6 downstream services affected, 4 API contracts would need revision - Relevant institutional memory: ADR-012 (the original UserService design rationale), FailurePattern-003 (a previous split attempt that failed due to distributed transaction complexity) - Response time: under 15 seconds

The architect has everything needed to make an informed decision before a single line of code is written. The cost of this analysis is zero.

Scenario: Preventing Circular Dependencies

Without Substrate: A circular import cycle develops gradually across three services over multiple sprints. Each individual change looks innocuous. By the time the cycle is complete and visible, it is deeply embedded in the codebase and requires significant refactoring to remove.

With Substrate: The substrate/no-circular-deps policy fires on the PR that completes the cycle — the first PR that creates a cycle at the service level, not after the cycle has been reinforced by subsequent changes. The tech lead is notified. The cycle is prevented before it can be established.

Scenario: Tech Debt Review and Sprint Retrospective Evidence

Without Substrate: The tech lead wants to make the case for a refactoring sprint, but the argument is subjective — "the codebase feels messy." The product owner pushes back because there is no quantitative evidence that tech debt is affecting delivery velocity.

With Substrate: The Proactive Maintenance Service generates a sprint health scorecard with quantitative signals: "Domain X coupling tension increased 40% this sprint. Service-layer violations: 7 new, 3 resolved. Drift score: 0.31 (up from 0.18 last sprint). Estimated cycle time impact: +28%." The tech lead brings quantitative evidence to the retrospective. The refactoring sprint is approved on measurable grounds.

Scenario: Policy Authoring and Enforcement

With Substrate: The tech lead authors a new architectural constraint as a Rego policy — "all services in the Finance domain must communicate via mTLS" — tests it against historical data to confirm it would not create unexpected blocks on existing services, and activates it. From that point forward, any PR that introduces a Finance domain service without mTLS configuration is blocked automatically. The enforcement is immediate, consistent, and requires no ongoing manual review by the tech lead.

3. DevOps / SRE

Primary value: Closing the gap between Infrastructure-as-Code declarations and runtime reality.

A DevOps engineer or SRE is responsible for the reliability and operability of the systems that developers build. Substrate gives them a ground-truth view of what is actually running, not just what was declared, and temporal graph capability that makes incident diagnosis dramatically faster.

Scenario: Simulation Before Terraform Apply

Without Substrate: An SRE is about to apply a Terraform change that modifies network segmentation for the payments cluster. The change looks correct in the diff, but the blast radius on dependent services is not fully understood. The apply proceeds, and an unexpected service timeout occurs in an adjacent cluster that shared a firewall rule.

With Substrate: Before running terraform apply, the SRE runs a simulation: "What services would be affected if I remove this network segmentation rule from the payments cluster?" The Simulation Service traverses the graph, identifies all services that rely on the current network path, and flags two services in an adjacent domain that would lose connectivity. The change is revised before apply. The incident does not occur.

Scenario: Incident Diagnosis via Temporal Graph Diff

Without Substrate: An incident occurs at 14:32. The SRE needs to understand what changed in the system in the hours before the incident. This requires correlating git commits, Terraform state diffs, Kubernetes deployment logs, and Datadog deployment markers — across four tools, with no unified timeline.

With Substrate: The query "what changed in the last 6 hours before 14:32 on Tuesday?" returns a unified time-scoped graph delta: services that changed, infrastructure nodes that changed, policy evaluations that fired, and drift events that were recorded. The SRE has a single, correlated timeline in under 5 seconds. The causal chain from change to incident is visible without cross-tool correlation.

Scenario: SSH Runtime Connector — Detecting Undeclared Services

Without Substrate: A developer deploys a debugging service directly to a production host without going through the standard deployment pipeline. The service is not registered in any IDP, not reflected in Terraform state, and not visible in the architecture graph. It runs for weeks, creating an undocumented network listener that becomes a security exposure.

With Substrate: The SSH Runtime Connector polls monitored hosts on a 15-minute cycle. On the next poll after the rogue service is started, it detects a process and port binding not present in the Intended Graph. A DriftNode is created with a GHOST_SERVICE classification. The SRE receives an alert within 15 minutes of the service starting. The undeclared service is documented, quarantined, or removed — not left running for weeks.

Scenario: IaC vs. Runtime Discrepancy

Without Substrate: The Terraform state says a particular service is running on three replicas on host prod-04. The actual host has two replicas because one failed to start and the health check is misconfigured to not report the failure. The discrepancy is invisible until a load spike hits.

With Substrate: The SSH Runtime Connector compares the declared replica count from Terraform state (Intended Graph) against the observed running process count from the host (Observed Graph). The discrepancy is flagged as a DriftNode with confidence score and timestamp. The SRE is alerted before the load spike reveals the gap.

4. Scrum Master

Primary value: Structural evidence for velocity conversations and proactive organisational risk detection.

A Scrum Master's effectiveness depends on the quality of the evidence they can bring to conversations about team health, delivery impediments, and systemic risk. Substrate provides quantitative structural evidence that transforms subjective retrospective discussion into data-driven organisational decision-making.

Scenario: Sprint Retrospective with Structural Evidence

Without Substrate: The team retrospective conversation about velocity is dominated by gut feelings: "it felt harder this sprint." The root cause — a 40% increase in inter-domain coupling that slowed every cross-service change — is invisible. The team agrees to "be more careful" without identifying the actual problem.

With Substrate: The Proactive Maintenance Service generates a sprint structural health report automatically at the end of each sprint: - Violation delta: 7 new policy violations introduced, 3 resolved - Coupling tension by domain: Domain X up 40%, Domain Y stable, Domain Z improved - Drift score trend: 0.31 this sprint vs. 0.18 last sprint vs. 0.12 two sprints ago (consistent degradation) - Cycle time correlation: estimated +28% cycle time attributable to structural coupling - Memory gaps opened: 2 new services with no WHY edges (ownership unclear)

The Scrum Master brings quantitative evidence to the retrospective. The conversation is grounded in data, not intuition. The team can address the specific structural problem, not a vague sense of friction.

Scenario: Key-Person Risk Detection with Escalation

Without Substrate: A senior developer announces they are leaving the team. Two weeks after their departure, the team discovers that five services have no documented ownership, three ADRs reference constraints that only that engineer understood, and two services have no second engineer with sufficient context to make changes safely.

With Substrate: When the developer's node is deactivated in the system, Substrate's Proactive Maintenance Service immediately scans for services with sole OWNS edges tied to that node. It finds five services meeting the criteria and generates a key-person risk alert with a 48-hour SLA for the Scrum Master and team lead: - List of affected services and their ownership status - Related ADRs that reference the departing engineer as decision author - MemoryGap flags for services with no second engineer with recent commit history - Recommended actions: ownership reassignment, knowledge transfer sessions, ADR review

The risk is surfaced proactively, before the engineer's last day, not discovered painfully after they have left.

Scenario: Tracking Structural Health Over Time

With Substrate: The Scrum Master maintains a structural health dashboard showing drift score trends, violation rates, coupling tension by domain, and memory gap counts across sprints. This provides a longitudinal view of architectural health that supplements velocity and story point metrics. When structural health deteriorates, the Scrum Master has early warning before the degradation manifests as delivery slowdowns.

5. Product Owner

Primary value: Understanding the architectural impact of product decisions before committing to them.

A Product Owner's effectiveness depends on making informed scope and priority decisions. Without architectural visibility, Product Owners routinely underestimate the complexity of features that touch structurally sensitive services, and overcommit based on surface-level scope assessments.

Scenario: Epic Impact Analysis

Without Substrate: The Product Owner writes an epic for a new payment flow feature. The estimate from the team is "2–3 sprints." Three sprints in, the team is still not done because the epic turned out to affect seven services across three domains, requiring API contract changes and a database schema migration that nobody had anticipated.

With Substrate: Before the epic is committed to a sprint, the Product Owner asks: "Which services does this epic affect?" The query is answered by the Reasoning Service using the epic's description and linked ticket context. It returns: - Affected service nodes with their domains and owners - API contracts that would need revision - Relevant ADRs that constrain the design space - Historical precedent: a similar change in Q2 required 4 weeks, not 2

The Product Owner has architectural scope visibility before committing. The sprint plan is realistic.

Scenario: Proactive Coupling Alerts on Velocity

Without Substrate: The Product Owner notices that delivery velocity on features in the legacy billing cluster has been consistently lower than in other parts of the system. The reason — a tightly coupled cluster of services with 14 shared dependencies and no clear domain boundary — is invisible to the Product Owner. They continue assigning stories to the team without understanding the structural impediment.

With Substrate: Substrate generates a proactive alert: "The billing cluster has a coupling coefficient 4x above baseline. Features touching this cluster are taking an average of 3.8x longer than comparably-scoped features in the payments cluster. Consider architectural investment or reduced scope allocation until coupling is addressed."

The Product Owner can make an informed decision: invest in architectural remediation, adjust velocity expectations for billing cluster features, or escalate the structural issue to the tech lead with evidence.

Scenario: Dependency Visibility for Roadmap Planning

With Substrate: When the Product Owner is building the quarterly roadmap, they can query: "Which services would need to change if we implement the new pricing model described in the roadmap?" The Simulation Service returns the affected service graph before any sprint planning begins, giving the Product Owner realistic scope information for roadmap-level decisions.

6. Business Analyst

Primary value: Business rules as first-class graph citizens; institutional memory queries in plain language.

A Business Analyst bridges business requirements and technical implementation. Substrate gives them a tool to verify that business rules are actually encoded in the system, detect gaps in institutional memory that put business requirements at risk, and query the system's intent in plain language.

Scenario: Business Rule Verification

Without Substrate: A Business Analyst is asked whether the system correctly enforces the rule that all refunds over $500 must go through manual approval. Verifying this requires interviewing developers, reading code, checking the Jira history, and hoping the relevant developer is still with the company.

With Substrate: The query "does the system enforce that refunds over $500 require manual approval?" returns the relevant graph nodes: the refund-service, its DEPENDS_ON edges to the approval-workflow-service, and ADR-019 which formalised this requirement. If the rule is enforced, the evidence is visible. If there is a gap — if the refund-service has a code path that bypasses the approval service — a PolicyViolation node will exist in the graph and be returned in the query results.

Scenario: Memory Gap Detection for Business Requirements

Without Substrate: A regulatory change requires updating a business rule that has been in place for four years. Nobody on the current team knows which services implement the rule, how it was originally specified, or what adjacent rules might be affected by changing it. The analysis takes two weeks of developer time.

With Substrate: The BA queries "which services implement the AML transaction monitoring rule?" The query returns the relevant service graph, the DecisionNode that formalised the implementation, and the FailurePattern from a 2022 incident where the rule was incorrectly bypassed. The BA has the complete implementation map and its history in seconds. MemoryGap flags highlight any parts of the implementation where institutional memory is incomplete.

Scenario: Encoding Business Rules as Graph Constraints

With Substrate: A BA works with the tech lead to encode a new business rule — "no service in the Customer domain may write directly to the Financial domain's database" — as a Rego policy. This policy is then reviewed, versioned, and activated. From that point forward, the business rule is machine-enforced at the PR level. The gap between business intent and technical implementation is permanently closed for this constraint.

Scenario: Querying Institutional Memory in Plain Language

With Substrate: The BA asks: "Why was the customer data masking approach changed in Q3 last year?" The Reasoning Service returns ADR-052, the post-mortem that triggered it, and the SprintInsight from the retrospective where the change was decided. No developer archaeology required.

7. Security Engineer

Primary value: Structural security enforcement, CVE blast radius computation, and ghost service detection.

A Security Engineer's architectural concerns extend beyond syntax-level vulnerabilities to structural security properties: are domain boundaries respected? Do services have clear ownership? Are there undeclared services running in production? Can a CVE in one dependency propagate laterally through the system? Substrate provides a structural security intelligence layer that SAST tools and CSPM platforms do not.

Scenario: Authoring and Enforcing Structural Security Policies

Without Substrate: The Security Engineer wants to enforce that all services in the Finance domain communicate exclusively via mTLS. This requirement exists as a document in Confluence. Enforcing it requires manual review of every PR that touches Finance domain services — which is not sustainable at any meaningful velocity.

With Substrate: The Security Engineer authors a Rego policy: substrate/finance-mtls-mandatory. The policy is version-controlled, tested against historical data, and activated. From that point forward, any PR that introduces a Finance domain service without mTLS configuration is blocked automatically. The enforcement is deterministic, consistent, and generates an audit trail for compliance reporting.

Additional structural security policy examples: - "No service may have a direct dependency on secrets-store unless it has an OWNS edge to a SecretsPolicy node" - "All services with PII data annotations must have an explicit GDPR_HANDLING edge" - "No external-facing service may depend on a service marked internal-only" - "All services in the Finance domain must have a designated security owner with active status"

Scenario: CVE Blast Radius Computation

Without Substrate: A new CVE is published affecting log4j-core. The Security Engineer needs to determine which of the organisation's services use this library. This requires searching repositories manually, checking dependency manifests, and hoping that no transitive dependencies have been missed. Classification and owner notification typically takes hours to days.

With Substrate: The Security Engineer triggers a CVE blast radius query: "Which services use log4j-core directly or transitively?" The graph traversal follows DEPENDS_ON edges from all service nodes to their library dependency nodes, identifying all affected services in under 15 minutes. The query returns: - Directly affected services (the library appears in their direct dependencies) - Transitively affected services (the library appears in a dependency's dependency) - Owners of each affected service (via OWNS edges) - Current patch status for each affected node

Owners are notified automatically via Slack and in-app alerts. The Security Engineer has a complete blast radius picture in minutes, not hours.

Scenario: Ghost Service Detection

Without Substrate: A developer spins up an ad-hoc debugging service on a production host. The service opens a network listener on a non-standard port and has write access to the application database. It runs undetected for six weeks before a security audit discovers it. By this point, it has been accessed from three unrelated IP addresses.

With Substrate: The SSH Runtime Connector detects the process and port binding on the next 15-minute poll cycle. A GHOST_SERVICE drift event is created. The Security Engineer receives an alert within 15 minutes of the service starting. The service is classified as UnauthorisedRuntime, and an escalation is triggered per the drift escalation policy. The exposure window is 15 minutes, not 6 weeks.

Scenario: Architectural Attack Surface Mapping

With Substrate: The Security Engineer queries "which services are externally reachable and have dependencies on services that handle PII?" The graph traversal crosses EXTERNAL_FACING, DEPENDS_ON, and HANDLES_PII edges to return the complete attack surface for data exfiltration scenarios. This structural security analysis would previously require a dedicated application security review engagement. With Substrate, it is a graph query.

8. Product Manager

Primary value: Architectural constraints made legible; roadmap feasibility simulation.

A Product Manager is responsible for making commitments on behalf of the organisation. Without architectural visibility, these commitments are made on the basis of developer estimates that may not account for structural complexity. Substrate gives the Product Manager a tool to validate feasibility before commitment and to understand what architectural investment is required to make a roadmap achievable.

Scenario: Roadmap Feasibility Simulation

Without Substrate: The Product Manager builds a quarterly roadmap that includes a major feature requiring the decomposition of the monolithic order-service. The team commits to the roadmap. Two months in, the tech lead reveals that the decomposition cannot be completed in Q2 because it would require resolving 23 circular dependencies first. The roadmap is revised. Stakeholders are disappointed.

With Substrate: Before the roadmap is finalised, the Product Manager asks: "Is the order-service decomposition feasible in Q2 given current architectural state?" The Simulation Service returns: - Current structural health of order-service: 23 circular dependency violations, 4 domain boundary violations, 2 unresolved MemoryGap flags - Estimated remediation effort based on historical velocity for similar structural work - Prerequisite architectural work that must be completed before the decomposition is safe - Historical precedent: the payment-service decomposition in Q3 last year took 6 weeks, not 3

The roadmap is built with accurate architectural constraints. Commitments are realistic.

Scenario: Feature Complexity Communication

Without Substrate: A Product Manager is asked by a stakeholder why a "simple" feature — adding a new loyalty points calculation — is taking three sprints. The PM has no way to explain the architectural complexity that makes the feature non-trivial: the loyalty calculation logic is entangled with the billing service, the reporting service, and three legacy adapters.

With Substrate: The PM queries "what is the structural complexity of adding a new loyalty calculation type?" The query returns the dependency graph for the affected area, the coupling coefficient, and the number of services that would need to change. The PM can communicate architectural complexity in concrete terms: "This feature touches 5 services, requires 2 API contract changes, and the affected cluster has a coupling coefficient 3x above baseline — which is why the estimate is 3 sprints, not 1."

Scenario: Constraint Legibility for Non-Technical Stakeholders

With Substrate: A business stakeholder asks "why can't we just add the new payment method directly to the checkout flow?" The PM queries Substrate and receives a plain-English explanation grounded in the actual architectural constraint: ADR-047 explains that all payment methods must be routed through the payments gateway for PCI compliance, FailurePattern-011 documents the 2023 incident that resulted from a direct payment integration, and the current enforcement policy prevents PRs that would bypass the gateway. The PM can explain the constraint with authority and evidence, not just "the tech team says no."

9. QA Engineer

Primary value: Blast radius computation for test planning, intent mismatch detection for scope creep, and FailurePattern surfacing for regression prevention.

A QA Engineer is responsible for understanding the full impact of a change before it reaches production. Without architectural visibility, test scope is determined by intuition and developer descriptions of what changed. Substrate provides a structural impact analysis that makes test planning systematic and evidence-based.

Scenario: Blast Radius for Test Planning

Without Substrate: A developer tells the QA engineer that a change "only touches the checkout service." The QA engineer scopes their test plan accordingly. In production, the change breaks the order history service because there was an undocumented dependency that neither the developer nor the QA engineer was aware of.

With Substrate: Before the QA engineer writes the test plan, they query: "What is the blast radius of the changes in PR #1847?" The graph traversal follows all DEPENDS_ON edges from the modified nodes, returning every service that could be affected by the change. The test plan is scoped to the actual blast radius, not the described blast radius. The undocumented dependency is visible in the graph. The regression is prevented.

Scenario: Intent Mismatch Detection for Scope Creep

Without Substrate: A PR is titled "Fix null pointer exception in checkout flow." The QA engineer scopes testing to the checkout flow. The diff, which they cannot fully analyse, also modifies the payment routing logic. The payment routing change introduces a regression that is not covered by the checkout-scoped test plan.

With Substrate: The Reasoning Service detects at PR creation time that the code change vectors have diverged significantly from the ticket intent embeddings. A comment is added to the PR: "Code changes appear to extend beyond the stated scope. Modified nodes include payment-router and transaction-validator, which are not referenced in ticket CHK-447. QA: expand test scope to include payment routing." The QA engineer's test plan is updated before review begins.

Scenario: FailurePattern Surfacing for Regression Prevention

Without Substrate: A developer makes a change to the message queue consumer configuration. The change looks correct. A similar change was made 18 months ago and caused a cascading failure in the notification service due to a message ordering assumption. The engineer who made the original change has left. The post-mortem is buried in a Confluence page that nobody reads. The same failure pattern is reintroduced.

With Substrate: When the PR modifying the message queue consumer is created, the Governance Service traverses the graph and finds FailurePattern-007: "Message queue consumer configuration changes that modify ordering guarantees have historically caused cascading failures in notification-service (PM-019, 2023-09-14)." A PR comment surfaces this FailurePattern. The QA engineer adds notification service testing to the regression suite. The failure is prevented.

Scenario: Regression Scope for Architectural Refactoring

With Substrate: A tech lead is preparing a major refactoring sprint. Before planning the test effort, the QA engineer asks Substrate: "What is the full test scope if we move all shared utility methods from shared-utils into domain-specific libraries?" The Simulation Service returns the complete set of services that import from shared-utils, the estimated number of integration points that would change, and historical data on how many regressions similar refactoring changes have produced. The QA sprint plan is scoped accurately, not speculatively.

10. Enterprise Architect

Primary value: System-wide reasoning via Global GraphRAG, portfolio-level governance, and policy enforcement at scale.

An Enterprise Architect is responsible for the long-term structural coherence of a large and complex system landscape. At this scale, manual oversight is impossible — the complexity exceeds any individual's mental model. Substrate provides the Global GraphRAG capability and portfolio-level governance tools that make enterprise-scale architectural oversight computationally tractable.

Scenario: System-Wide Reasoning via Global GraphRAG

Without Substrate: The Enterprise Architect needs to answer the question: "Which of our 200 services are potential single points of failure?" Answering this requires collecting data from multiple systems — Backstage (some services are registered), LeanIX (some capabilities are mapped), Datadog (some dependencies are visible through traces), Confluence (some architecture diagrams exist). The answer takes weeks and is immediately out of date.

With Substrate: The query "identify services with high fan-in dependency counts and no redundant alternatives" is answered by the Global GraphRAG against the live architecture graph. The Reasoning Service traverses the complete DEPENDS_ON graph, identifies nodes with unusually high in-degree, cross-references with OWNS edges to check for single ownership, and returns a ranked list of architectural risk candidates with evidence. The Enterprise Architect has a current, comprehensive answer in under 60 seconds.

Scenario: Portfolio-Level Policy Governance

Without Substrate: The Enterprise Architect establishes a technology standards policy: "All new services must use the approved message queue implementation (RabbitMQ). Kafka usage is deprecated and should not be introduced." This policy exists in a document. Enforcement relies on architecture review boards catching violations in design sessions, which only covers larger initiatives. Small teams introducing Kafka in new services go undetected until a portfolio review 6 months later.

With Substrate: The Enterprise Architect authors the policy as a Rego rule in the enterprise/technology-standards policy pack. The policy is deployed to all teams on the Scale or Enterprise tier. Every PR across every team is checked against this policy. New Kafka introductions are blocked at the PR level across the entire portfolio. The Enterprise Architect receives a weekly summary of all blocked violations, approved exceptions, and open exception requests. Policy compliance is measurable, not aspirational.

Scenario: Compliance Evidence Generation

Without Substrate: An audit requires evidence that all services handling personal data have documented data flow mappings, clear ownership, and encryption-at-rest policies. Generating this evidence requires a 3-week effort by two architects pulling information from multiple systems, some of which is missing or out of date.

With Substrate: The Enterprise Architect runs a compliance query: "Generate audit evidence for all services with HANDLES_PII annotations." The query returns a structured report covering each PII-handling service, its ownership (OWNS edges with owner contact details), its data flow mappings (graph traversal of RECEIVES_DATA and SENDS_DATA edges), its encryption policy linkage (Rego policy coverage), and any open compliance gaps (services with missing GDPR_HANDLING edges flagged as ComplianceGap nodes). The evidence is current as of the last graph sync. Generation time: minutes.

Scenario: Architectural Debt Quantification for Investment Decisions

With Substrate: The Enterprise Architect needs to justify a significant architectural investment to executive stakeholders. Substrate provides quantitative evidence: - Portfolio-wide drift score trend over 12 months - Coupling coefficients by domain, with high-coupling clusters identified - Violation count and trend by policy category (structural, security, ownership, documentation) - Estimated cycle time impact of current architectural debt levels (based on historical correlation in the graph) - FailurePattern density: number of known failure patterns per domain, and which patterns have been repeated

The investment case is grounded in evidence, not architectural intuition.

Scenario: Onboarding and Knowledge Transfer at Scale

With Substrate: A large organisation onboards 30 new engineers across 5 teams in a quarter. Without Substrate, each engineer's architectural ramp-up requires weeks of pairing with senior colleagues, reading outdated documentation, and making mistakes that senior engineers catch in review.

With Substrate, every new engineer can query the system's architectural history in natural language: "What is the history of the payments service?", "Why does the order service not communicate directly with the inventory service?", "What decisions were made about the current authentication architecture?" The Global GraphRAG provides complete, cited answers drawn from ADRs, post-mortems, and institutional memory nodes. The architectural ramp-up time is substantially reduced, and the quality of understanding is higher because the source is the actual architectural record, not the memory of senior colleagues.