/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/denied are flat strings — no per-capability tier or reason
The v1 docs promised allowed: [{ capability, tier, reason }] and "every entry cites the tier that
decided and a human-readable reason." Live, allowed and denied are flat arrays of
capability-name strings — there is no tier or reason per entry on v0.9.9. Treat this 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"]
}allowed_scope_types is the canonical enum — but not enforced on writes
allowed_scope_types is the canonical scope-type list, though scope-type validation is not
enforced on writes (see Scopes). The v1 docs' defaults example
(diagnostics_allowed / experimental_enabled) does not match — those keys are not returned.
PUT policy mutation endpoints are not wired
PUT /v1/policy/{deployment|tenant|scope|actor} → 405 on v0.9.9 (verified live; not merely
"experimental") — the mutation endpoints are unshipped. Set policy via deployment presets and env, not
these routes.