Govula Substrate
The canonical infrastructure layer of the Govula platform.
Substrate is the institutional backbone every Govula product reads from. Canonical truth, governance structure, federation, observability and audit lineage — named, bounded and adopted, never invented.
Intelligence
Operational governance intelligence
Substrate
Canonical truth, governance structure, lineage
APIs
GOESL · SPL · GDIL · GSPL
Federation
Per-tenant RLS STRICT, semantic alignment
Observability
Read-only projections, replay-verified audit
Boundary
Substrate, named by what it is not.
Architects, auditors and operators read the same boundary on the first page.
Substrate is not
- A dashboard or operator console.
- A control plane or runtime decision surface.
- A synthetic operator UI over existing systems.
- A new abstraction layer over the eight canonical surfaces.
Substrate is
- The canonical infrastructure layer of the Govula platform.
- The system of truth every Govula product reads from.
- The institutional substrate for tenancy, federation and audit lineage.
- A positioning surface over already-canonical infrastructure.
Core capabilities
Four institutional layers, each canonical.
Every layer names the canonical document an institution actually adopts. Nothing here introduces a new runtime.
Canonical Truth Layer
A concept lives in one canonical home. Older artefacts are preserved with a deprecation banner and never extended in place. CARL (Canonical Authority & Resolution Layer) is the institutional resolution mechanism.
Governance Structure Layer
Structured governance lifecycles, immutable decision lineage, named-human authority on every binding state change. AI may analyse, suggest and draft; AI may not approve, sign, publish or mutate governance state.
Observability Foundation
Platform observability view, distributed governance signals and operational intelligence surfaced as read-only projections. Replay verifier recomputes the audit chain end-to-end; the replay outcome is itself audited.
Federation Model
Per-tenant Row-Level Security in STRICT mode plus a single hardened repository module. Cross-organization semantic alignment binds shared operational terms to single canonical homes. Tenant isolation is structural, not a runtime check.
Architecture
Canonical Governance Stack
One platform shape. Five conceptual layers. The diagram describes the layers an institution adopts; it does not introduce new runtimes.
Top
Governance Intelligence
Operational layer where institutions read decisions, lineage and proof.
Middle
Governance Substrate
Canonical truth, governance structure and audit lineage — the institutional backbone.
Bottom
APIs · Federation · Observability
Canonical surface catalog, per-tenant RLS STRICT, read-only observability projections.
Conceptual stack. Each tier names a canonical document an institution adopts.
Adoption paths
Three documented entry points.
Substrate is adopted progressively. Pick the entry that matches the institutional reading you are doing today.
Evaluate
Read the substrate.
No integration. Read the canonical documentation, the architecture paper, and the SDK reference. Establish institutional fit before any connection.
Open documentation →SDK integration
Connect light.
Read-only adoption through the SDK. Surface adapters (GOESL · SPL · GDIL · GSPL) and the canonical tenant identity context bind your environment without operational dependency.
Open SDK docs →Enterprise integration
Adopt the platform.
Five-stage institutional adoption lifecycle, role binding for SRE / Security / Engineering / API / Legal, full deployment topology.
Enterprise activation →Each path is reversible. Reading substrate documentation never creates an operational dependency; the canonical adoption progression is documented in the enterprise activation lifecycle.
Connection model
How institutions bind to the substrate.
The connection layer is read-only by default. Every binding is named, every surface is canonical, every identity is institutionally scoped.
Surface adapters
GOESL · SPL · GDIL · GSPL are the four canonical adapter surfaces. Reads route through these; no consumer reaches a non-canonical path.
SDK hook model
The SDK exposes typed read hooks against each canonical surface. Hooks publish canonical projections; they do not invoke runtime verdicts or mutate governance state.
Governance identity context
Tenant identity is issued as a scoped JWT and propagated as the canonical tenant context. The platform binds this context to PostgreSQL Row-Level Security STRICT at the connection boundary; no read path can observe a different tenant.
RLS STRICT + hardened repository
RLS STRICT is layered with a single hardened repository module whose raw client accessor is hard-thrown. Tenant isolation is structural, not a runtime check, and not negotiable per connection.
The connection layer never publishes a runtime verdict. It publishes canonical state and routes reads. Operational decisions remain with named human roles per the institutional charter.
Operational modes
Three progressive modes of operation.
Each mode changes the institutional dependency on the substrate, not the substrate's behaviour. Progression is reversible at every step.
01
Observation mode
Read-only. The substrate publishes canonical projections; the institution reads them. No write path is opened; no operational dependency is created.
02
Alignment mode
Institutional terms are bound to canonical homes through documented mappings. Internal vocabulary aligns to the substrate without renaming canonical surfaces.
03
Full adoption
The institution operates against the substrate as a canonical dependency under the five-stage adoption lifecycle. Role binding is documented; reversibility is preserved.
Institutional infrastructure properties
Append-only audit integrity
Canonical observability
Multi-tenant isolation
Institutional replay verification
Governance traceability
Deployment
Institutional topologies, documented end-to-end.
Substrate is built for Railway (backend) and Vercel (frontend) with Neon PostgreSQL. The deployment hub names every supported topology, scaling, backup and recovery path.
Enterprise deployment
Five-stage adoption lifecycle: Evaluation → Shadow Mode → Read-Only Integration → Observability Alignment → Full Operational Dependence. Progression changes organizational dependency, not system behaviour.
Tenant isolation
PostgreSQL Row-Level Security STRICT plus a single hardened repository module whose raw client accessor is hard-thrown. Tenant isolation is a structural property of the substrate.
Observability integration
Platform observability view, distributed governance signals and operational intelligence as read-only projections; never as runtime verdicts.
Auditability model
Three SHA-256 hash-chained append-only ledgers, each made immutable at the database layer. Replay verifier recomputes the chain end-to-end and the replay outcome is itself audited.
SDK · Documentation
Read the substrate. Adopt the platform.
Substrate is read first, integrated second. Each entry below points at the canonical document an institution actually adopts.
SDK docs
External adoption guide, API surface catalog, integration templates — calling existing canonical APIs.
Open SDK docs →Architecture paper
Enterprise architecture map: five-layer proof architecture, surface taxonomy, audit chain replay.
Open architecture →Deployment guides
Deployment hub: supported topologies, scaling, backup & recovery, CI/CD, secrets, observability, troubleshooting.
Open deployment hub →Onboarding guides
Institutional deployment playbook, five-stage adoption lifecycle, role binding for SRE / Security / Engineering / API / Legal.
Open onboarding →Enterprise
Adopt the platform the way your institution operates.
Substrate is the foundation. Intelligence is the operational surface. One Govula Platform account. One identity. One audit lineage.