Policy Terminology
Define the identities, revision records, delivery evidence, and recovery terms used throughout Policy.
Policy uses different records for authored work, approved content, and target delivery. Similar names do not make those records interchangeable. This reference explains the distinctions used in task instructions and error messages.
Authoring and Governance
The following table defines terms for authoring and governance:
| Term | Meaning and Boundary |
|---|---|
| Authored intent | Describe the author’s selected classifications, principals, methods, and permissions, before target-specific compilation. |
| Authoring lane | Distinguish Data authoring from artificial intelligence (AI) authoring. Their inputs and supported protection choices differ. |
| Classification | Identify a category of discovered data. Its current resolved locations determine Data scope. |
| Scope | Identify the data locations or runtime subjects affected by the selected policy inputs. A display name alone does not establish scope. |
| Principal | Identify a runtime subject, such as a configured directory group. Do not confuse it with the person administering Policy. |
| Draft | Hold proposed policy work that can proceed through saving, submission, review, and approval. |
| Draft identity and cycle | Keep the stable draftPolicyId separate from its cycleNumber. A later authoring cycle can retain the same draft identity. |
| Snapshot | Retain a particular saved state of authored work. Saving again does not create another approved revision. |
| Draft head | Identify the draft’s current saved snapshot. Inspect its current status and validator before changing it. |
| Governed revision | Record content that completed approval. An open replacement draft does not replace this content. |
| Compilation minor | Record changed compiled output under an existing governed revision without changing its authored intent or approval attribution. |
| Review acknowledgement | Record an authorized acceptance of a specifically reviewable finding. Do not use it to bypass a blocking conflict. |
For example, saving a corrected draft changes proposed work. Approval creates governed content. Automatic recompilation can then change generated output without another author edit. Refer to states and revisions.
Identity and Request Evidence
The following table defines identity and request-evidence terms:
| Term | Meaning and Boundary |
|---|---|
| Authentication token | Establish the caller’s authenticated identity through the supported gateway. Keep it secret. |
| Authority | Identify a permission asserted by the trusted platform. Clients must not invent identity or authority headers. |
| Command capability | Permit an operation, such as policy:approve. Ownership of a policy does not supply that capability. |
| Policy access grant | Assign owner or editor access to particular authored work. Commands can also require a separate capability. |
| Entity tag (ETag) | Identify an opaque server-issued resource validator. Send its exact quoted value in the required If-Match header. |
| Idempotency key | Identify one exact reconciliation decision for safe replay after an uncertain response. Do not reuse it for different intent or evidence. |
| Service user | Authenticate background integration calls. Keep this identity separate from human users and Kubernetes workload identities. |
pmx_app | Name a fixed PostgreSQL NOLOGIN permission role inherited by the runtime login. It is not another account requiring a password. |
| Identity provider (IdP) | Supply directory or identity-source information. Shared connection metadata does not grant Policy command authority. |
An application programming interface (API) request can require authentication, a command capability, a policy grant, and a resource validator. Each satisfies a different condition. Refer to roles and permissions and API authentication.
Compilation, Delivery, and Protection
The following table defines compilation, delivery, and protection terms:
| Term | Meaning and Boundary |
|---|---|
| Compilation | Convert policy intent and current source context into target-specific configuration. |
| Artifact | Hold generated target configuration, not an editable draft or proof of active protection. |
| Publication | Deliver approved artifacts to the relevant integration. Verify the operation’s required completion evidence separately. |
| Deployment generation | Number successive publication or removal requests for a policy. Retry keeps the same generation and increases the attempt count. |
| Outbox | Retain queued publication or withdrawal work durably in Policy’s database. A queued event is not completed delivery. |
| Worker lease | Reserve queued work for a worker for a limited time. Expiry can delay reassignment after process loss. |
| Terminal operation | Stop ordinary automatic processing after failure. Use the permitted recovery path rather than assuming a restart retries it. |
| Consumer receipt | Record a matching consumer read of the artifact. Do not treat it as proof of activation, real-traffic enforcement, or every replica’s receipt. |
| Protection evidence | Establish the applicable target-specific result, such as current positive Data observations. Healthy services alone do not provide it. |
| Fail-closed recompilation | Keep the last accepted configuration when fresh inputs or validation fail. Do not automatically deny all traffic. |
Refer to background processing and delivery verification.
Ownership and Recovery
The following table defines ownership and recovery terms:
| Term | Meaning and Boundary |
|---|---|
| Native object | Identify an object in a target product, such as Policy Workbench, rather than a Policy draft or governed revision. |
| Ownership binding | Connect a saved Policy reference to a native object’s unique identifier. Names and reference keys do not substitute for that identifier. |
| Stale validator | Describe request evidence that no longer matches the current resource. Re-read and review before deciding again. |
| Stale binding | Describe a saved ownership mapping whose native object may be absent. Complete inventory and blocker checks must establish cleanup safety. |
| Deployment retry | Resume delivery of configuration saved for a failed request, without compiling later draft edits or fresh discovery. |
| Ownership reconciliation | Choose which Policy Integration Manager (PIM) object Policy associates with a saved reference, using the inspection response and system-configuration permission. |
| Policy rollback | Start an In Review draft from a prior governed revision. Do not treat it as immediate target replacement, database recovery, or Helm rollback. |
| Database restore | Replay a selected backup into the in-stack database under an approved recovery plan. External target changes require separate reconciliation. |
| Release qualification | Confirm compatible chart, API, Panel, PostgreSQL, and storage versions, including a tested migration and restore procedure. |
For recovery actions and authority requirements, use the recovery directory. For installation limitations, consult known issues.
Feedback
Was this page helpful?