Policy Architecture

Policy separates user-facing governance from asynchronous delivery and target observation. Its web interface and application programming interface (API) share the same backend contracts. Traverse supplies classifications and protection observations. Policy Integration Manager (PIM) receives Data policy configuration. Federated Guardrails consumers retrieve their configuration. An artifact is the target-specific output generated from governed policy intent. Delivery transfers that output. Protection evidence describes the target-specific result.

High-Level Block Diagram

PostgreSQL belongs to the Policy stack. The platform gateway and target integrations have their own operational responsibilities.

flowchart TB
    User[Author or reviewer] --> Gateway[Platform gateway and identity]
    Gateway --> Panel[Policy web interface]
    Panel --> Gateway
    subgraph Policy stack
        API[Policy API and background processing]
        DB[(PostgreSQL)]
        API --> DB
    end
    Gateway --> API
    API -->|Read discovery and protection observations| Traverse
    API -->|Publish native policy work| PIM[Policy Workbench]
    Consumer[Federated Guardrails consumer] -->|Retrieve product policy through gateway| Gateway

Federated Guardrails retrieves its product policy through the supported consumer route. Do not interpret the diagram as a push into every runtime replica. The external artificial intelligence (AI) runtime belongs to its own deployment.

Block Diagram Terms

The following table defines the components and responsibilities shown in the diagram:

Policy Workflow

The author selects scope, principals, and supported protection inputs. Saving retains proposed work. Submission hands its current snapshot to review. An authorized approver creates a governed revision and queues publication. Background processing then delivers artifacts and collects the relevant evidence.

Automatic recompilation can refresh artifacts from approved intent when context changes. It preserves approval identity and does not replace an author’s open draft. Refer to System operations.

Governance and Recovery Boundaries

The local database records Policy governance and delivery state. Restoring this database does not undo changes already made in PIM or configuration already retrieved by Guardrails. Before resuming publication, the platform and integration administrators must compare restored records with the configuration in those products.

A retry continues retained deployment work. Ownership reconciliation addresses native identity and binding decisions. Native means an object in the target product, rather than Policy’s own governance record. A binding associates a Policy reference with that object’s identifier. Neither operation substitutes for reviewing newly authored policy content. Refer to recovery playbooks.