Internal Marketplace¶
The Substrate Marketplace is the mechanism for scaling architectural knowledge across organisations and across the Substrate user community. It allows teams to package best practices as versioned, reusable artefacts — and allows the community to build, share, and monetise governance intelligence at the same level of rigour as application code.
The marketplace solves a fundamental problem in governance tooling: the hardest part of adopting a governance platform is not the technical integration — it is deciding what to govern. A team adopting Substrate for the first time needs a starting set of policies that encode established software engineering principles, a set of connectors for their existing toolchain, and a way to share their own standards as they develop them. The marketplace provides all three.
Artifact Types¶
1. Policy Packs¶
Policy Packs are named, versioned, curated bundles of OPA/Rego policies targeting specific architectural concerns, design standards, or compliance frameworks. They are the primary unit of governance knowledge in the marketplace.
A Policy Pack is:
- Named and versioned: substrate/solid-principles@v1.2.0
- Self-contained: all Rego files, test files, and documentation bundled together
- Testable: every pack includes Rego unit tests that run in CI against the deploying organisation's graph before activation
- Documented: each rule includes a plain-English explanation that surfaces in PR block messages
- Configurable: packs expose configuration parameters (e.g., similarity threshold for DRY detection) that organisations can tune without modifying the Rego source
MVP Launch Policy Packs¶
The following packs are Substrate Official and included at no additional cost in all paid plans:
| Pack Name | What It Enforces |
|---|---|
substrate/no-circular-deps |
Detects and blocks cycles in the DEPENDS_ON graph at the service level |
substrate/api-gateway-first |
Enforces that all external-facing services route via an API gateway; no direct external exposure |
substrate/service-ownership |
Requires that every service node has at least one active OWNS edge; blocks ownerless services |
substrate/license-compliance |
Detects GPL/AGPL/LGPL licenses in production dependencies; blocks incompatible license introduction |
substrate/solid-principles |
Enforces Single Responsibility (class-level cohesion), Dependency Inversion (import direction), and Interface Segregation (interface fan-out) |
substrate/dry-patterns |
Flags code blocks with Jaccard similarity >80% across service boundaries as duplication candidates |
substrate/tdd-coverage |
Enforces configurable test coverage thresholds by service and domain |
substrate/api-first |
Requires that all services expose an OpenAPI spec before implementation code is accepted |
Extended Policy Pack Categories¶
As the marketplace matures, additional packs covering the following categories are planned:
| Category | Example Pack Names |
|---|---|
| Security | substrate/finance-mtls-mandatory, substrate/pii-handling-controls, substrate/secrets-rotation-policy |
| Compliance | substrate/soc2-controls, substrate/gdpr-data-flow, substrate/pci-dss-boundary |
| Domain Patterns | substrate/event-driven-patterns, substrate/saga-pattern-enforcement, substrate/strangler-fig-validation |
| Team Health | substrate/ownership-coverage, substrate/adr-freshness, substrate/postmortem-encoding |
| Performance | substrate/dependency-depth-limits, substrate/fan-out-constraints, substrate/database-per-service |
Community Policy Packs¶
Community contributors can publish Policy Packs to the marketplace. Community packs go through a trust tier evaluation process before being made available to the broader community (see Trust Tiers below). A community contributor who has developed internal standards for their organisation's architectural patterns — event sourcing rules, specific domain boundary conventions, team-specific coding standards — can publish these as a pack, set a monthly price, and earn revenue from other organisations that adopt the same patterns.
2. Connector Plugins¶
Connector Plugins are containerised ingestion workers that implement Substrate's standard extract → transform → emit interface. They allow any tool in an organisation's existing toolchain to become an ingestion source for the UMKB.
A Connector Plugin: - Implements the standard interface: extract (pull data from the source tool), transform (map to Substrate's canonical node/edge schema), emit (write to the UMKB via the Ingestion Service's gRPC endpoint) - Is containerised: runs as a Docker container in the Substrate infrastructure; no direct database access - Is versioned and signed: each release is versioned; Substrate Official and Community Verified connectors have image digests verified before deployment - Is configurable: connection credentials, polling intervals, and field mappings are configurable without modifying the container image
MVP Official Connectors¶
The following connectors are Substrate Official and included at no additional cost in all paid plans:
| Connector | Source | What It Ingests |
|---|---|---|
substrate/github |
GitHub repositories | Code, file structure, import graphs, PR history, review comments |
substrate/github-projects-v2 |
GitHub Projects | Epics, tickets, sprint assignments, milestone relationships |
substrate/github-pages |
GitHub Pages / wikis | Documentation nodes, ADR pages, team wikis |
substrate/terraform |
Terraform state / HCL | Infrastructure declarations, resource dependencies, provider configurations |
substrate/kubernetes |
Kubernetes API | Running workloads, service mesh topology, config maps, secrets references |
Note: The SSH Runtime Connector is a built-in core service of the Governance Service, not a marketplace plugin. It is not replaceable or removable, and it does not go through the marketplace trust tier process.
Community Connector Examples¶
| Connector | Source | Status |
|---|---|---|
community/jira |
Atlassian Jira | Community Verified |
community/confluence |
Atlassian Confluence | Community Verified |
community/linear |
Linear | Community Unverified |
community/datadog |
Datadog metrics & alerts | Community Verified |
community/pagerduty |
PagerDuty incidents | Community Unverified |
community/slack |
Slack messages (decision capture) | Community Verified |
community/notion |
Notion pages | Community Unverified |
community/gitlab |
GitLab repositories | Community Verified |
Custom connectors for proprietary or niche tools not available in the marketplace can be developed via the Additional Connector add-on ($2,500 one-time).
Trust Tiers¶
Every artefact in the marketplace carries a trust tier badge. Trust tiers communicate the level of review, testing, and accountability that stands behind the artefact.
| Tier | Badge | Review Process | Availability | SLA Backing |
|---|---|---|---|---|
| Substrate Official | ✅ Official | Full Substrate team review; automated test suite; image digest signed; SLA-backed | All paid plans | Yes |
| Community Verified | ✅ Verified | Substrate team security audit; image digest pinned; test coverage checked; author identity verified | Team+ plans | No |
| Community Unverified | ⚠ Unverified | No formal review; install at own risk; community feedback visible | Team+ plans | No |
| Org Private | 🔒 Private | Internal to the publishing organisation; no external review required | Scale / Enterprise only | Internal only |
Trust Tier Evaluation Process¶
Community Verified status requires: 1. Author submits an artefact with a complete description, test suite, and changelog 2. Substrate's trust team reviews the artefact for security issues (no credential exfiltration, no undeclared external calls, no persistent storage outside the standard interface) 3. Automated scanning checks for known vulnerable dependencies and licence compliance 4. Image digest is pinned and published in the marketplace manifest 5. A minimum of 3 independent community installations with positive feedback is required before Verified status is granted
Community Unverified artefacts are available immediately after submission. They carry a prominent warning in the UI and must be explicitly acknowledged by an admin before installation. Unverified artefacts are not available to Starter plan users.
Org Private artefacts are published by Scale and Enterprise organisations to their internal namespace. They are not visible to other organisations and do not go through any Substrate trust review. Internal governance of Org Private artefacts is the responsibility of the publishing organisation.
Revenue Model¶
Artifact Monetisation¶
The marketplace supports two pricing tiers for community artefacts:
Free: The artefact is available to all eligible plan tiers at no additional cost. Most community artefacts start as free to build reputation and user base.
Paid: The author sets a monthly subscription price in the range of $5–$199/month per installing organisation. Substrate processes payments and takes a 20% platform share. The author receives 80% of subscription revenue.
Revenue share applies only to community artefacts. Substrate Official artefacts are always free and included in plan pricing. Org Private artefacts do not generate revenue share — they are internal knowledge assets.
Pricing Rationale for Community Authors¶
A community author who develops a high-quality Rego policy pack for, say, event-driven architecture enforcement patterns, and prices it at $49/month, needs only 26 installing organisations to generate $1,000/month in revenue ($49 × 26 × 0.80 = $1,019.20). The development investment is a one-time cost; the revenue is recurring. This creates genuine economic incentive for high-quality community contributions.
Custom Development¶
The Additional Connector add-on ($2,500 one-time) covers cases where an organisation needs a connector for a proprietary or niche tool that is not available in the marketplace and where the organisation lacks the internal capability to build it themselves. Substrate's connector team develops the connector to the standard interface and delivers it as an Org Private artefact. If the connector is subsequently open-sourced to the community marketplace, the revenue share model applies.
The Context Moat: Competitive Flywheel¶
The marketplace is not just a distribution mechanism for governance artefacts. It is the primary driver of Substrate's long-term competitive moat — what the Substrate team calls the Context Moat.
How the Context Moat Forms¶
When an organisation begins using Substrate, the initial value comes from the official Policy Packs and Connectors: structural governance, institutional memory encoding, and live architecture graph construction. This is the baseline value.
Over time, the organisation begins accumulating artefacts that are unique to their context:
- Org-Private Policy Packs that encode their specific architectural conventions, technology standards, and domain boundary rules
- WHY edges that link constraints to the specific incidents, decisions, and trade-offs that are part of their history
- DecisionNodes that represent their ADRs, with their reasoning
- FailurePatterns drawn from their post-mortems
- Custom LoRA fine-tuned models (Enterprise) trained on their codebase vocabulary
The graph ceases to be a generic architecture graph. It becomes a precise, queryable representation of the organisation's architectural DNA — the accumulated product of every decision made, every incident survived, and every constraint established over the life of the system.
Why the Moat Is Defensible¶
The Context Moat is defensible for a reason that has nothing to do with lock-in: the accumulated institutional memory cannot be reconstructed by switching to a different tool.
A competitor tool can replicate Substrate's feature set. It cannot replicate the years of WHY edges, DecisionNodes, and FailurePatterns that represent the organisation's unique architectural history. Those artefacts exist only in Substrate's graph, encoded in a form that is queryable, enforceable, and machine-legible.
The switching cost is not contractual — it is epistemic. Leaving Substrate means losing the institutional memory that Substrate has accumulated. The longer an organisation uses Substrate, the more accurate the statement: "the knowledge in this graph is irreplaceable."
Community Flywheel¶
The marketplace creates a community flywheel that strengthens Substrate's position in the market:
- More organisations adopt Substrate → more demand for community artefacts
- More community authors build artefacts → richer marketplace, lower time-to-value for new adopters
- Lower time-to-value for new adopters → more organisations adopt Substrate
- Each organisation accumulates a Context Moat → switching cost increases, renewal rates improve
- High renewal rates → Substrate can invest more in the platform → richer official artefacts → better community tooling → repeat
The marketplace is the mechanism by which the community encodes collective architectural intelligence into reusable, monetisable form — and the mechanism by which Substrate's value compounds beyond what any single organisation's internal investment could achieve alone.
Example: Scaling Organisational Knowledge¶
An organisation uses Substrate for 18 months. During that time:
- 47 ADRs are encoded as DecisionNode artefacts with WHY edges
- 12 post-mortems are encoded as FailurePattern nodes
- 8 Org-Private Policy Packs are developed encoding internal architectural standards
- 3 Org-Private Connectors are built for internal tooling
- The Custom LoRA model (Enterprise tier) is trained on 18 months of the organisation's codebase
At this point, the Substrate graph is not a generic architecture tool. It is a precision instrument calibrated to this specific organisation's system, history, and culture. A new engineer joins and can ask questions about the system's history in plain language and receive answers grounded in 18 months of institutional memory. An architect can run a simulation and receive results that factor in constraints established by incidents that happened before the current team was assembled.
This is the Context Moat: not a feature, but an accumulation of value that compounds over time and is impossible to reproduce elsewhere.