Frequently Asked Questions

Quick answers to the questions most teams ask when evaluating and operating Govula — what it does, how governance behaves, and how to deploy it confidently.

Looking for deeper operational guidance and platform documentation? Explore the Knowledge Base.

CONTINUING FROMStarting new reasoning thread

REFERENCE

Frequently Asked Questions

Category & Positioning

Govula is, primarily, a Governance Intelligence Platform (GIP). It is a deterministic runtime that detects governance signals continuously, decides what to do via attributable policy logic, acts inside a bounded reversible enforcement envelope under explicit human approval, and proves every step into a hash-chained, tamper-evident audit ledger. The platform expresses three supporting facets in technical contexts: Governance Cognition Infrastructure (the detect → decide → act → prove pipeline), Governance Observability System (the ledger, replay verifier, and trust-center surface), and Operational Governance Layer (the runtime tier above evidence sources and beside any existing GRC tool). See docs/enterprise/category-definition.md for the full treatment.
"Governance Operating System" is retained as the architectural trajectory — the direction the platform is evolving toward as cohort-aware enforcement, the sovereign-tenant operator boundary, and the full Phase C operator capability set ship. Today, some of those capabilities are Beta or Planned in the Phase 1 Audit §12. Calling Govula a Governance Operating System today would over-claim in the same way "AI magic" over-claims AI. Governance Intelligence Platform is the category a CIO, CISO, or procurement lead can evaluate honestly right now.
Govula sits above your evidence sources (SIEM, scanners, ticketing, attestation) and beside any existing GRC tool. It does not replace SIEM and it does not replace GRC. A GRC tool stores what humans claim; Govula runs the loop deterministically and the audit ledger is the product. SOAR runs scripted security playbooks; Govula governs decision authority with reversible enforcement and a governance-shaped audit. See docs/enterprise/competitive-positioning.md.

Technical

Node.js 20 with TypeScript in strict mode, Express 5 on the backend, Next.js 15 (React 19) on the frontend, PostgreSQL (Neon in production) as the data store.
Every database call goes through one hardened repository module. Tenant-scoped queries set the tenant ID inside a transaction so row-level security holds across pooled connections. The raw client accessor is intentionally hard-thrown so no caller can bypass the guard.
A request ID is propagated through every log line and every audit row, so an operator can pivot from a log to the exact governance event it caused.

Governance

DETECT → DECIDE → ACT → PROVE. The system observes risk signals continuously, applies deterministic policy logic, executes a narrowly bounded set of reversible actions, and writes every step into the immutable audit ledger.
Why this answer

SYSTEMDetects, decides, acts, proves — deterministically, continuously, in order.→YOUYou authorise the act; the system cannot.

WHY

Without deterministic order, evidence and authorisation drift apart and the audit becomes a story rather than a chain.

CONSEQUENCE

If a step is skipped, the chain breaks — the replay verifier returns a mismatch, not a recovery.

The user who initiates a governance decision cannot approve it. This is enforced in service code and recorded structurally on the decision row. There is no admin override.

SYSTEM

Blocks self-approval at service, repository, and trigger layers.

The decision row records initiator and approver as distinct identities.

YOU

Cannot approve what you initiated.

There is no admin override. You delegate the second signature, you do not bypass it.

Why this answer
RULEGovernance Constitution

RULEGovernance Constitution

DERIVED FROMNo upstream provenance · system root

Enforcement runs at API middleware, service layer, and database trigger level. There is no "skip governance" flag. Direct database writes against immutable ledgers are blocked by Postgres rules.

Executive

Govula runs the loop that produces compliance — detect, decide, act, prove — inside a deterministic, reversible-where-it-matters, hash-chained audit ledger.
No — the platform does not mutate governance state without an explicit human approval at the approval-chain gate. Within declared policy budgets, the operational enforcement layer (CEAL-2) carries out reversible actions that have been human-approved; each action carries a rollback handle and the reversal itself is audited. Anything outside the policy budget escalates to a human. SAFE_MODE halts all new state-changing routes across the estate with a single switch. AI is recommendation-only and may not approve, sign, publish, or mutate governance state.

SYSTEM

Executes only reversible actions inside human-approved policy budgets.

Anything outside the budget escalates; SAFE_MODE halts all state-changing routes.

YOU

Approve every binding action by name.

AI never signs. Each approval records you as the actor.

Why this answer
SOURCEAI Safeguards

SOURCEAI Safeguards

DERIVED FROMNo upstream provenance · system root

Approve, sign, or publish on behalf of a human. Modify customer infrastructure or run agents on customer hosts. Override its own immutability rules. Issue MFA enrolment today (the session flag exists; TOTP enrolment is Beta).

Architecture

PostgreSQL Row-Level Security in STRICT mode (no bypass-on-null). All application access is funnelled through the single hardened repository module that sets the tenant ID inside a transaction.
Three distinct chains, each with its own hash payload — one for general governed actions, one for tenant-side governed operations, and one for platform-side operator actions. Each chain is append-only at the database level.
Platform staff act on a tenant only inside a separately-authenticated, time-bounded, capability-scoped elevation session. Each elevation requires a reason of at least 10 characters and a recent re-authentication; missing recent re-auth is denial, not warning.
Why this answer

SYSTEMGrants tenant access only inside a separately authenticated, time-bounded session.→YOUState a reason of at least 10 characters before crossing the tenant boundary.

WHY

Tenant access without a reason is access without a record.

CONSEQUENCE

Elevation without recent re-authentication is denial, not a warning. Phase C capabilities are locked and cannot be invoked.

RULEAuthority Model

RULEAuthority Model

DERIVED FROMNo upstream provenance · system root

Deployment

Railway (backend) + Vercel (frontend) + Neon (PostgreSQL). The schema bootstrap is idempotent — fresh databases reach steady state on first boot.
Docker (Shipped), self-hosted (Shipped), hybrid (Beta), and federated peer-to-peer (Shipped). The deployment hub tags every guide with a status against the Phase 1 audit.

Security

JWT authentication, then role authorisation middleware, then service-layer authority checks, then database triggers. The UI and the API share the same enforcement chain.

SYSTEM

Validates JWT, role middleware, service authority, and DB triggers on every call.

UI and API share the same enforcement chain — neither can outrun the other.

YOU

Hold the role at the moment of action, not the moment of grant.

Recent privilege changes are reflected before your next request resolves.

Why this answer
RULEAuthority Model

RULEAuthority Model

DERIVED FROMNo upstream provenance · system root

The session model carries an MFA-verified flag and enforces it at sensitive checkpoints, but TOTP enrolment is not yet shipped end-to-end. Do not represent MFA as a fully shipped capability without that caveat.
Database rules block UPDATE and DELETE on every immutable ledger; SHA-256 hash chaining lets any reader recompute the chain end-to-end. The replay verifier writes its own outcome into the operation log — the audit of the audit is itself audited.

SYSTEM

Blocks UPDATE and DELETE on every immutable ledger via Postgres rules.

SHA-256 hash chaining lets any reader recompute the chain end-to-end.

YOU

Run Verify Integrity when you need to prove the chain is intact.

The replay verifier's outcome is itself written into the audit.

Why this answer
RULEAudit Logs

RULEAudit Logs

DERIVED FROMNo upstream provenance · system root

Investor

GRC tools (ServiceNow GRC, Archer, OneTrust) are systems of record — they store what humans claim. Govula runs the loop deterministically and the audit ledger is the product. Every UI surface reads from it; the proof layer replays from it; the verifier validates it end-to-end.
SOAR (XSOAR, Sentinel, Splunk SOAR) runs scripted playbooks per deployment, with the SIEM as the audit. Govula's audit ledger is governance-shaped, hash-chained, and the verifier returns one of three spec-locked phrases surfaced verbatim.
Phase C operator capabilities (impersonation, governance freeze, incident execution), a managed sovereign-tenant deployment posture, full MFA enrolment, and broader entitlement-engine adoption on high-value routes.

AI Governance

AI in Govula is AI-assisted recommendation that requires human approval before any governance state mutates. AI may analyse, suggest, and draft. AI may not approve, sign, publish, or mutate governance state. Every binding state change records a named human actor.
Why this answer

SYSTEMAnalyses, suggests, and drafts — never signs, publishes, or mutates state.→YOUYou are the named actor on every binding change.

WHY

Authority that cannot be attributed is authority that cannot be revoked.

CONSEQUENCE

An AI-authored binding change would name no actor — there would be no one to escalate to and no one to remove.

SOURCEAI Safeguards

SOURCEAI Safeguards

DERIVED FROMNo upstream provenance · system root

The recommendation pipelines that produce governance artefacts are audited; one underlying helper service emits prompt completions that are not yet routed through the audit log. The platform claim is therefore narrowed: "AI calls that produce governance decisions or remediation tasks are audited."
Yes. AI features are entitlement-gated; tenants can opt out.

Federation

Govula speaks an open Governance Protocol Standard — six-field Ed25519-signed envelopes between independent deployments. Each peer scores trust observationally, based on what peers actually do, not on a vendor-managed reputation score.
Yes. Two known caveats are documented in the audit: the public verify endpoint is intentionally public (rate-limited), and the onboarding endpoint is currently unauthenticated by bug. A separate task is open to lock down the second.

Audit

Open the decision record. Verify the decision class, the authority required, the user who approved and their role at the time, the evidence the decision referenced, and the integrity hash. The Proof Layer replays the recorded execution against the same data the audit ledger holds.
Why this answer

SYSTEMSurfaces decision class, authority, approver, evidence, and integrity hash on the record.→YOUOpen the record, verify the chain, replay the execution.

WHY

Auditing is recomputation, not trust. The chain only counts if you can recompute it yourself.

CONSEQUENCE

A decision that cannot be replayed is, for audit purposes, a decision that did not happen.

SOURCEAuditor Walkthrough

SOURCEAuditor Walkthrough

DERIVED FROMNo upstream provenance · system root

It calls the audit-stream verify endpoint, recomputes the SHA-256 hash chain end-to-end, and returns one of three spec-locked phrases surfaced verbatim: "Integrity verified. This record is consistent and tamper-evident." / "Verification failed. Data inconsistency detected." / "Verification unavailable for this record."
The replay walks every row in deterministic order, recomputes the chain root, and persists the result into the operation log. If the chain is intact, the response says so; if it is not, the mismatches are recorded and the replay outcome is itself audited.

Go deeper

  • Documentation hub — vocabulary glossary, capability source of truth (Phase 1 Readiness Audit), stakeholder positioning.
  • Deployment hub — every supported topology, with Implemented / Partial / Planned / Aspirational tags.
  • Governance Constitution — decision classes, authority model, separation of duties.
  • System boundaries — explicit non-goals, including the AI authority boundary.

Still have questions? Contact support