Architecture paper
Govula Architecture.
A governance substrate for institutional-scale systems. This document names the layers, the canonical surfaces and the governance constraints that define the platform.
I. System overview
Three institutional layers.
Govula is composed of three layers. Each layer has one canonical home; this document only names them.
Top
Intelligence
The product surface institutional operators read for governance signal — detected risk, decided actions, executed safely, proven. AI may analyse, suggest and draft; AI may not approve, sign, publish or mutate governance state.
Middle
Substrate
The canonical infrastructure layer of the platform: canonical truth, governance structure, federation, observability foundation and audit lineage. The system of truth every Govula product reads from.
Foundation
Platform
The institutional account boundary, identity, tenancy and shared adoption surface. The entry point under which Intelligence and Substrate operate as named institutional products.
II. Canonical surfaces
Named, bounded, never duplicated.
Eight canonical surfaces define the platform. A concept lives in one canonical home (Phase 4 §IV). This document references each by name; the canonical module remains the source of truth.
Governance Object & Event Surface List
Canonical surface catalog. The institutional inventory of named governance objects and events the platform exposes.
Surface Publication Layer
The publication contract over canonical surfaces. Reads are routed through this layer; the layer itself is the documented contract.
Governance Data Interpretation Layer
Canonical interpretation of governance data. Institutions read GDIL projections; new interpretation logic is not added externally.
Governance State Publication Layer
Canonical publication of governance state for institutional consumers. Read-only at the surface boundary.
SDK distribution manifest
The external adoption guide and integration templates. The institutional way to consume the canonical surfaces from outside the platform.
Observability layer
Distributed governance signals and operational intelligence surfaced as read-only institutional projections — never as runtime verdicts.
Audit ledgers
Three SHA-256 hash-chained append-only ledgers, each made immutable at the database layer. The replay verifier recomputes the chain end-to-end; the replay outcome is itself audited.
SLO descriptor
The named institutional service-level boundary. Adopted as a documented descriptor, not invoked as a runtime check.
Deep-detail reference: canonical architecture document.
III. Governance model
Historical closures that bound the system.
The platform is a closed architecture. The following closures define how it behaves; new proposals are evaluated against them, never around them.
- ODRH
Operational lock chain
Operational Deployment & Runtime Hardening. Closed by prior art; named as canonical doctrine, externally referenced.
- PRDV
Production validation boundary
Production Readiness & Deployment Validation. Externalized as a documented release-validation description, not a runtime check.
- RDA
External activation model
Operational Phase 1 Activation. Activation is an institutional act performed and recorded externally; the platform does not invoke it.
- PR-1
Rollout control rejected
No platform-managed rollout API. Rollout is an institutional decision recorded as such.
- IH-1
Hardening computation rejected
No platform-computed hardening verdict. STABLE / DEGRADED / UNSTABLE are human-recorded states only.
- Step 3
Ecosystem and product layer
Defined as institutional explanation only — no extension over the eight named canonical surfaces.
- Phase 4
Institutional Constitution
The binding §IV evaluation rule for every future proposal: must not be already canonical, must not be a runtime verdict, must not be a deployment / rollout / operational control, must not be a new abstraction over the eight named surfaces. No override.
- Step 5
Institutional adoption lifecycle
Five stages, role binding. The institutional contract for how organizations adopt the platform.
- Step 6
Multi-organization consistency
Interpretation-consistency and cross-organization semantic mapping. Shared operational terms bind to single canonical homes across institutions.
IV. Deployment reality
What Govula is, and is not.
Govula is not
- A runtime control system over your infrastructure.
- A platform that takes binding actions on its own.
- A new abstraction layer over the canonical surfaces.
- A replacement for the systems the institution already operates.
Govula is
- A governance interpretation layer over existing institutional infrastructure.
- A canonical reference for governance lineage and audit.
- A surface every binding state change is named on by a human.
- A closed institutional architecture, externally adopted and operated.
All execution occurs in canonical systems already defined. Govula names, observes, interprets and audits — and records every binding state change as a named-human act.
Closing
Govula does not evolve structurally. It is interpreted, adopted and operated externally.
System state: closed architecture. Phase 4 §IV applies to every future proposal — without override.