Skip to main content

Architecture

OpenProdkt Governance is organized around product modules instead of implementation details.

That means customers can understand what each part of the product does without needing to know how the stack is wired behind the scenes.

HTTP and gRPC use separate trusted-context adapters over one canonical PEP request and the same HTTP /v1/evaluate PEP-to-PDP contract. MCP is a future first-class adapter, not a generic HTTP wrapper; it must normalize tools/call, tool/server identity, session context, and tool arguments explicitly without changing HTTP or gRPC policy semantics.

Module map​

  • Identity and workspace
  • Governance decisions
  • Inventory
  • Approvals and history
  • Access and permissions
  • Delivery and integrations
  • Console experience

How modules connect​

Foundation modules establish who is calling; Core modules define what is governed and decide the outcome. Everything downstream reads from this chain rather than adding its own edges back into it.

Core modules fan out to just two surfaces: the API/SDK/webhook delivery layer, and the Console. Splitting this from the dependency chain above keeps either diagram readable on its own.

Governance decisions are the center of the product. Policies reference inventory (assets and groups), and outcomes flow through approvals where needed. The console and API surfaces let teams manage every part of this flow.

Identity and workspace​

This module covers the first user experience:

  • create an organization
  • sign in with a one-time code
  • view the current user and workspace
  • manage members and workspace settings

Customers should think of this module as the entry point to the product.

Governance decisions​

This module is responsible for the product's decision flow:

  • define what is being governed
  • create policies
  • evaluate requests
  • return one of three outcomes: allow, approval_required, or deny

Inventory​

This module gives customers a way to describe the assets they want to govern:

  • assets
  • groups
  • discovered assets

It helps customers connect real-world workflows to governance rules.

Approvals and history​

This module shows what happened after a request was evaluated:

  • pending approvals
  • approve and reject actions
  • decision history
  • audit history

The goal is to make governance outcomes visible and traceable.

Access and permissions​

This module controls who can do what:

  • human sign-in roles
  • API key permissions
  • workspace-level visibility

The product keeps human access and machine access separate so customers can manage both cleanly.

Delivery and integrations​

This module covers the ways the product connects to customers' systems:

  • public API endpoints
  • SDKs
  • async webhook delivery of approval lifecycle events (recommended default), plus app-managed retry, short-wait, and polling as alternatives — see Approvals & Webhooks

Licensing​

Plans and licensing are covered separately in Licensing & Distribution.

Where it runs​

OpenProdkt is built to run wherever your organization needs it:

  • Any major cloud provider, using each provider's managed services for the best fit and cost.
  • On-premises, including fully air-gapped environments with no outbound connectivity.

The underlying infrastructure — queues, databases, notifications, and storage — is interchangeable behind the scenes. This means Enterprise customers are never locked into a specific cloud vendor or infrastructure choice, and can move or mix environments as their needs change.

Console experience​

This module is the browser experience customers use to manage governance work:

  • dashboard
  • page navigation
  • policy authoring
  • approval handling
  • decision review

The console is a surface over the modules above, not a separate product.