Unique Selling Points¶

Substrate is defined by six core differentiators that separate it from traditional catalogs, monitoring platforms, and Enterprise Architecture tools. These are not feature claims — they are structural capabilities that no combination of existing tooling delivers simultaneously.

The Six Differentiators¶

1. Preservation of Architectural "Why"¶

The problem every other tool ignores.

Every tool today tells you what exists. Backstage tells you what services are registered. LeanIX tells you what capabilities are mapped. SonarQube tells you what code quality metrics look like. No tool tells you why the architecture is the way it is — and that missing layer is the primary driver of both Structural Drift and Memory Loss.

Substrate captures the full spectrum of institutional reasoning as first-class graph citizens:

Source	Graph Artefact	Linked Via
ADR (GitHub / Confluence)	`DecisionNode`	`WHY` edge to governed nodes
Post-mortem (Confluence / Jira)	`FailurePattern` node	`CAUSED_BY` + `PREVENTS` edges
Design rationale (PR comments)	`MemoryNode`	Linked to affected code nodes
Policy exception	`ExceptionNode`	`WHY` edge with expiry date
Sprint retrospective	`SprintInsight` node	Linked to team + sprint nodes
Informal decision (Slack)	`IntentAssertion` node	`ASSERTS` edge to governed node
Unresolved tribal knowledge gap	`MemoryGap` flag	`MISSING_CONTEXT` on node

When a developer asks "why does the payment service have to route through the gateway?", Substrate returns the full provenance: the production incident that caused the rule, the ADR that formalised it, the Rego policy that enforces it today, and the engineer who authored it. This answer would previously have required tracking down two or three senior engineers who might not remember, or might have already left.

WHY edge density increases over time. The more architectural decisions get made and encoded, the richer every query and simulation becomes. This is the compounding mechanism that creates the Context Moat.

Memory decay is actively monitored. Substrate tracks staleness signals and escalates through a defined chain:

Day 0: Owner DM via Slack + in-app badge
Day 3: Reminder to owner + last editor
Day 7: Escalation to team channel
Day 14: Escalation to team lead + architecture board
Day 30: Auto-deprecation — node marked Stale

Staleness thresholds by artefact type:

Artefact	Staleness Threshold
Service dependency edge	14 days
API contract / OpenAPI spec	30 days
Service ownership (`OWNS` edge)	90 days
ADR	180 days
Post-mortem lesson	365 days

Memory decay signals that trigger proactive alerts:

Service with no ADR → WHY edge missing; MemoryGap flag created
ADR references a deleted service → orphaned DecisionNode detected
Stale decision never reviewed (>180 days, no REVIEWED_AT timestamp)
Post-mortem not encoded as policy (FailurePattern with no linked Policy node)
Key person departure risk: developer node deactivated while holding sole OWNS edges on services
Duplicate documentation: embedding similarity >85% across two nodes

2. Simulation Before Code Is Written¶

The only platform that shifts governance left of the IDE.

No competitor offers pre-change what-if analysis at the architectural graph level. The closest alternatives — architecture review boards, RFC processes, and informal "spike" tickets — operate on documents rather than computable models, take days to weeks, and produce no machine-enforceable output.

Substrate's Simulation Service allows an architect or tech lead to describe a proposed change in natural language. The engine:

Translates the natural language description into a set of graph mutations (nodes added, edges changed, policies affected)
Runs the current full OPA/Rego policy suite against the mutated graph
Computes the blast radius delta — which services, contracts, and owners are affected
Surfaces relevant institutional memory — past decisions, incidents, or exceptions that relate to this change
Returns a before/after policy comparison in under 15 seconds

The output is not advisory. It is the same deterministic policy evaluation that will fire on the actual PR when code is eventually written. There are no surprises at review time.

Example use cases:

"What happens if I split the UserService into UserReadService and UserWriteService?"
"What policies would fire if we removed the API gateway requirement for internal services?"
"What services would be affected if we deprecated the legacy authentication connector?"
"Show me the blast radius if the payments service loses its database connection"

This capability shifts the cost of architectural decisions to zero. A simulation that prevents one misinformed refactoring sprint pays for the entire annual subscription.

3. SSH Runtime Verification¶

The gap no IDP closes.

Internal Developer Portals and CMDB tools rely on teams to correctly declare what is running. Infrastructure-as-Code tools declare what should be running. The gap between declaration and reality — between the Intended Graph and the Observed Graph — is the gap that produces the 40% CMDB accuracy figure Gartner reports, and the production incidents that follow.

Substrate's agentless SSH Runtime Connector closes this gap without requiring any agent installation on target hosts. It connects via standard SSH, collects:

Running process list with PIDs and command lines
Active port bindings and listening services
Installed package names and versions
Config file checksums for declared configuration paths

This observed state is compared against the Intended Graph. Any discrepancy becomes a Drift node with a measured confidence score, a timestamp, and a link to the expected topology.

No existing IDP platform does this. Backstage relies on catalog-info.yaml files that developers must maintain. Port.io relies on API integrations that require deliberate registration. Wiz and Datadog observe cloud-layer signals but have no concept of what should be running according to the architectural intent. None connect via SSH to compare declared versus actual at the host level.

The SSH Runtime Connector is a built-in core service, not a plugin or add-on. It operates on a configurable polling interval (default: 15 minutes for drift detection, 5-minute burst during active incidents).

4. Hardened GraphRAG¶

Addressing the 73–84% reasoning failure rate of baseline implementations.

Microsoft's baseline GraphRAG approach, and the community of tools that have adopted it, share a set of well-documented failure modes:

Entity hallucination: Retrieval generates plausible but fabricated graph nodes; these entities get treated as real and propagate through subsequent queries
No temporal reasoning: Graph snapshots are static; there is no way to ask "what was the architecture three weeks ago?" or "what changed between the incident and the current state?"
Post-retrieval reasoning failures: 73–84% of errors in baseline GraphRAG occur not in retrieval but in the reasoning step — the model fails to correctly synthesise retrieved context into a coherent answer
Context window saturation: Naive retrieval floods the LLM context with loosely relevant nodes, degrading answer quality on complex multi-hop queries

Substrate's Reasoning Service addresses each failure mode with specific techniques:

HyDE (Hypothetical Document Embeddings)¶

Before retrieving from the graph, Substrate generates a hypothetical ideal answer to the query. This hypothetical document is then embedded and used as the retrieval query, rather than embedding the raw question. HyDE systematically closes the lexical gap between how humans ask questions and how architectural knowledge is stored in the graph.

Example: The question "which services could be affected by a payment processing outage?" is rephrased as a hypothetical answer describing payment service dependencies, blast radius patterns, and ownership — then that hypothetical is used to retrieve matching graph context.

RAPTOR (Recursive Abstractive Processing for Tree-Organised Retrieval)¶

For complex multi-hop queries that span many graph nodes, flat retrieval produces too much noise. RAPTOR builds a hierarchical summary tree over the graph: leaf nodes are individual graph entities, and parent nodes are LLM-generated summaries of clusters of related entities. Queries are answered at the appropriate level of abstraction — a high-level question about system architecture retrieves from summary nodes; a specific question about a single service retrieves from leaf nodes.

This prevents context window saturation on complex queries and produces more coherent answers on system-wide reasoning tasks.

Hybrid RRF Fusion¶

Substrate fuses three independent retrieval signals using Reciprocal Rank Fusion (RRF):

Dense vector retrieval: Semantic similarity via bge-m3 embeddings stored in PostgreSQL pgvector
Sparse BM25 retrieval: Keyword-based retrieval for exact technical terms, service names, and error codes
Graph traversal: Cypher-based structural retrieval following typed relationship edges in Neo4j

No single retrieval method is reliably best across all query types. RRF fusion combines the ranked results from all three methods into a single ranked list without requiring model-specific score calibration. The result is retrieval that is simultaneously semantically aware, keyword-precise, and structurally grounded.

Temporal Reasoning via Graph Snapshots¶

Every node and edge in the Substrate graph carries created_at, updated_at, and valid_until timestamps. The graph maintains versioned snapshots at configurable intervals. This enables queries such as:

"What did the service topology look like 72 hours before the incident?"
"Which policies have changed in the last 30 days?"
"Show me the drift delta between last Tuesday and today"
"Which services changed ownership in Q4?"

Baseline GraphRAG implementations have no answer to temporal queries. Substrate's temporal layer is a core feature, not a post-hoc extension.

Grounded Citation¶

Every answer Substrate returns includes citations: the specific graph nodes, edges, ADRs, and policies that the answer is drawn from. Engineers can verify the provenance of any claim. This eliminates the trust problem with LLM-generated architectural advice — every statement is traceable to a specific, reviewable source.

5. Active Governance, Not Passive Observation¶

The difference between a thermostat and a smoke alarm.

IDPs catalog. Observability platforms sense. EA tools plan. Substrate blocks.

The architectural governance tools that precede Substrate are fundamentally passive. A score in Backstage or Port.io that says "this service has 3 violations" does not prevent those violations from being merged. A LeanIX capability map that shows a deprecated technology in use does not prevent new services from adopting it. A Datadog alert on a dependency graph anomaly does not prevent the engineer from deploying the change that caused it.

Substrate is the only platform that actively prevents architectural violations at the PR level, before violations reach production:

OPA/Rego policy evaluation runs synchronously in the CI/CD pipeline on every PR
Deterministic result: pass or block, with no probabilistic middle ground
Plain-English explanation: every block includes a human-readable reason, not a rule code
ADR citation: every block links to the specific architectural decision that established the rule
Fix suggestion: every block includes a concrete remediation path

The choice of OPA/Rego over LLM-based enforcement is deliberate and architectural:

Rego is deterministic — the same input always produces the same output
Rego is version-controlled — policies are code; changes are reviewed and audited
Rego is testable — policy unit tests can be written and run in CI
Rego produces a complete audit trail — every evaluation records the input, the policy version, and the output
Rego is explainable — any stakeholder can read a Rego policy and understand what it enforces

LLM-based enforcement fails all five criteria. A governance system that produces different results on identical inputs cannot be relied upon for compliance, cannot be audited, and will be challenged and overridden by engineers who receive inconsistent results.

6. Complete Data Sovereignty¶

For organisations where data leaving the building is a non-starter.

Every major AI-powered developer tool on the market — GitHub Copilot, Cursor, CodeRabbit, Qodo, Snyk — sends source code to external APIs. For many organisations in regulated industries, defence, financial services, healthcare, and high-security environments, this is not a trade-off that can be made. It is a compliance violation.

Substrate is designed from the ground up for complete data sovereignty:

All AI inference runs on the DGX Spark node: Llama 4 Scout MoE (for reasoning), Dense 70B (for complex analysis), Qwen2.5-Coder (for code understanding), and bge-m3 (for embeddings)
No external API calls: No calls to OpenAI, Anthropic, Google, or any third-party inference provider during normal operation
All data stored locally: Neo4j and PostgreSQL run on the customer's hardware
Air-gap compatible: Enterprise tier supports fully air-gapped deployment with no internet connectivity requirement
Custom LoRA option: Enterprise customers can fine-tune models on their own codebase and terminology — the fine-tuned weights never leave the organisation

This is not a feature that can be bolted on to a cloud-first architecture. It requires that the entire inference stack — model weights, embedding models, vector indices, and graph databases — run on customer-controlled hardware. Substrate's DGX Spark target provides sufficient compute for all inference workloads within the MVP team size.

Capability Gap Matrix¶

The following matrix shows Substrate's capability coverage against the leading tools in adjacent categories. No single competitor and no combination of two competitors covers all rows.

Capability	Backstage	LeanIX	Wiz	Datadog	SonarQube	Substrate
Live architecture graph from code	❌	❌	❌	❌	Partial	✅
Active PR blocking on arch violation	❌	❌	❌	❌	Partial	✅
Institutional memory (why layer)	❌	❌	❌	❌	❌	✅
Pre-change simulation	❌	❌	❌	❌	❌	✅
SSH runtime verification	❌	❌	❌	❌	❌	✅
NL graph queries	❌	❌	❌	❌	❌	✅
SOLID/DRY/TDD policy packs	❌	❌	❌	❌	Partial	✅
Verification queues (AI routing)	❌	❌	❌	❌	❌	✅
Fully local inference	N/A	N/A	❌	❌	Partial	✅
Unified Code+Infra+Docs+Project	❌	Partial	❌	Partial	❌	✅

Partial denotes that the tool covers a narrow subset of the capability in a way that does not satisfy the full requirement. For example, SonarQube provides "active PR blocking" but only for syntax-level quality gates — it has no concept of domain boundary violations, ownership enforcement, or circular dependency detection at the architectural graph level. Similarly, SonarQube provides "fully local inference" in the sense that it runs on-premise, but its analysis is rule-based, not model-based; it has no inference stack equivalent to Substrate's.

GraphRAG Hardening: Technical Summary¶

The following table summarises the specific failure modes of baseline GraphRAG and the Substrate technique that addresses each.

Baseline GraphRAG Failure	Substrate Counter-Measure
Entity hallucination baked into graph	Graph nodes require source citation; orphan nodes flagged automatically
No temporal reasoning	All nodes/edges carry timestamps; versioned snapshots support time-scoped queries
73–84% post-retrieval reasoning failures	RAPTOR hierarchical retrieval reduces context noise; HyDE improves retrieval precision
Lexical mismatch between query and stored knowledge	HyDE generates a hypothetical ideal answer as the retrieval query
Flat retrieval saturates LLM context window	RAPTOR multi-level abstraction retrieves at the appropriate level of detail
Single retrieval method misses relevant nodes	Hybrid RRF fusion across dense, sparse, and graph traversal signals
Unverifiable AI claims	Every answer includes citations to specific graph nodes, edges, and policies
No structural grounding	All retrieval includes graph traversal; answers reference the live topology