/v1/policy
Inspect the effective capability set for an actor+scope and the deployment policy.
CortexDB resolves capabilities through a four-tier stack — deployment → tenant → scope → actor. These read-only endpoints let you inspect the result. See Authorization for the model.
Effective capabilities
GET /v1/policy/effective?actor=&scope= → 200:
{
"actor": "user:alice",
"scope": "org:acme/user:alice",
"deployment_preset": "dev_local",
"natural_level": "...",
"allowed": ["scope.write", "scope.read.holistic", "..."],
"denied": ["..."],
"rate_limits": { "...": "..." }
}allowed and denied are capability names
allowed and denied are flat arrays of capability-name strings (no per-entry tier or reason);
the response also carries natural_level and rate_limits. Use it as a capability check, not an
explanation.
Deployment policy
GET /v1/policy/deployment → { preset, allow, deny, defaults } (self-host: preset: "dev_local",
allow: ["*"]). The defaults block is the deployment's real knobs:
{
"actor.require_signed": false,
"scope.auto_register": true,
"forget.cascade.default": "derived_only",
"audit.retention": "...",
"rate_limit.write": "...", "rate_limit.read": "...",
"allowed_scope_types": ["org","dept","team","app","user","agent","service","ws","project","global","system","debug","temp","source"]
}allowed_scope_types is enforced when a scope is created (v0.9.10+)
allowed_scope_types is the canonical scope-type list, and since v0.9.10 a write that would create a
new scope segment of another type is refused with 422 UNREGISTERED_SCOPE_TYPE (existing scopes keep
working, see Scopes). Before v0.9.10 it was advisory only.
Policy is set by preset and environment
The policy routes are read-only: set policy with the deployment preset (CORTEX_DEPLOYMENT_PRESET) and
environment. PUT /v1/policy/deployment answers 405, and there are no PUT routes for the tenant,
scope or actor levels (404).