Policy Violations — Proposed Guide

Planned API — Reference Only

Policy Violations: A violation representation would explain which policy rule was not satisfied. It should support review without implying that every…

Overview

A violation representation would explain which policy rule was not satisfied. It should support review without implying that every warning is an automatic rejection.

Key concepts

Record rule identity, evaluated policy version, severity and supporting facts. Distinguish warnings from blocking decisions.

Implementation considerations

An override should require its own authority and rationale. Do not erase the original violation when an exception is approved.

Proposed API behavior

GET /v1/expenses/{expense_id}/policy-violations is an illustrative design for this topic. Path and field names may change before implementation. Access would require an authorized organization context and operation-specific permission; no public API or authorization grant is available here.

Proposed path parameters
Name	Type	Description
expense_idrequired	string	Stable fictional expense reference; not a secret and not evidence that a resource exists.

No additional request fields are illustrated; this is not a finalized contract.

Static example requests

Proposed, non-executing request examples

# Proposed request text only; this reserved host is not a live API.
curl -X GET 'https://api.remizen.example/v1/expenses/exp_example_123/policy-violations' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Fictional response example

200 (proposed example)Static response fixture

Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.

JSON

{
  "data": {
    "expense_id": "exp_example_123",
    "policy_id": "policy_example_123",
    "rule_id": "rule_example_123",
    "severity": "severity example",
    "id": "exp_example_123",
    "organization_id": "org_example_123",
    "merchant": "Example Office Supply",
    "amount_minor": 12550,
    "currency": "USD",
    "status": "draft"
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: An override should require its own authority and rationale. Do not erase the original violation when an exception is approved.

422 (illustrative; final error contracts are undecided)Proposed error fixture

Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.

JSON

{
  "error": {
    "code": "validation_error",
    "message": "The proposed policy violations operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
expense_id	string	Stable fictional expense reference; not a secret and not evidence that a resource exists.
policy_id	string	Stable fictional policy reference; not a secret and not evidence that a resource exists.
rule_id	string	Stable fictional rule reference; not a secret and not evidence that a resource exists.
severity	string	Illustrative severity value; interpret it only within the proposed topic-specific model described above.

Expense Policies

Expense Management

Expense Tags