policy-rule-add

Adding a new policy rule involves translating legal or eligibility requirements into predicate logic, stable flag codes, and audit-ready rationale strings. You then wire the predicate into PolicyAgent.run behind a trigger condition to maintain consistent enforcement.

The standard structure for policy rule creation requires a new predicate method, wiring it into PolicyAgent.run, updating tests and PRD, and optionally adding an Alembic migration. This ensures side-effect-free predicate methods and consistent staff console rendering.

Yes, adding eligibility or denylist checks requires positive and negative tests along with a PRD row update. These quality guardrails keep staff console rendering consistent and ensure safe extensibility with hard or soft flag behavior.

You should add an Alembic migration when your new budget or overdue-related policy rule reads a new persistent table. This database schema update is optional and only required if the predicate logic depends on querying newly introduced persistent data.

Configuring hard vs soft flag behavior involves defining trigger conditions and side-effect-free predicate methods within the PolicyAgent. This safe extensibility guardrail ensures your rule blocks patrons or warns based on the specific eligibility or cost-cap violation logic.

The best way to standardize audit rationale strings is to follow existing conventions when turning legal requirements into predicate logic. This standardization prevents inconsistent policy enforcement and maintains uniform formatting across all flag codes and rationale outputs.