Skip to main content
Status: A unified configurable public policy engine is unavailable. Praxa’s existing product has multiple mature fail-closed gates; the current minimal /v1/execute handler derives authority server-side and rejects the request policy override.

What exists now

Praxa has domain-specific gates for browser actions, purchases, connector writes, social actions, credentials, and other consequential product behavior. Those gates refuse unsafe execution when approval or authority is absent. They are relevant safety foundations, but they are not one customer-configurable public engine. The first source-ready public approval refinement exposes only an exact immutable browser action. It remains pending production activation and does not generalize to every domain.

Planned unified contract

The planned engine would evaluate deterministic server-owned inputs at a small set of commit chokepoints and return one of: Planned inputs include tool capability, effect classification, monetary and sensitive-category thresholds, anomaly signals, tenant policy, and scoped standing grants. Planned policy packs would be named and versioned. None of that vocabulary makes peer review, customer policy authoring, standing grants, request risk ceilings, model-lane pins, tool allowlists, or policy receipts live today.

Current request behavior

The SDK reserves a policy object, but the active handler rejects the entire field before task creation. A caller cannot tighten or loosen policy through /v1/execute yet. Identity, tenant, roles, funding, and task admission remain server-derived.

Required invariants for future activation

  • unknown, unsupported, and evaluation-error cases fail closed;
  • no prompt or model judgment can grant authority;
  • every adapter proves identical-or-stricter behavior against its existing product gate;
  • the displayed action equals the recorded action and resume-gate input;
  • policy versions cannot be rewritten under historical evidence;
  • organization approver authority is rechecked at the decision boundary;
  • activation follows evaluation, migration, deploy, and live negative canaries.

Receipts remain separate

Current public runs and events do not expose a mature policy-version receipt. Hash-chained evidence, policy replay, approver identity, and export remain planned even though narrower internal task and approval records exist.

See also

Last modified on August 14, 2026