{ "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://flex-auth.netkingdom/schemas/check_request.schema.json", "title": "CheckRequest", "type": "object", "additionalProperties": false, "required": ["subject", "action", "resource"], "properties": { "id": {"type": "string", "minLength": 1}, "tenant": {"type": "string", "minLength": 1}, "subject": {"$ref": "#/$defs/subject_ref"}, "action": {"type": "string", "minLength": 1}, "resource": {"$ref": "#/$defs/resource_ref"}, "context": {"type": "object", "additionalProperties": true}, "caring_context": {"$ref": "https://flex-auth.netkingdom/schemas/caring_access_descriptor.schema.json"}, "policy_version": {"type": "string", "minLength": 1} }, "$defs": { "subject_ref": { "type": "object", "additionalProperties": false, "required": ["id"], "properties": { "id": {"type": "string", "minLength": 1}, "type": { "type": "string", "minLength": 1, "description": "The requesting system's own subject-type vocabulary, evaluated by its policy package as an opaque string. Deliberately NOT the CARING subject_type enum: that enum is the registry's vocabulary (subject_manifest.yaml, where Service is correct), and every shipped consumer sends its own on the request instead -- human (user-engine), service (tenant-engine, secrets-engine), adm/agt/atm (ops-warden, which is an actor-type vocabulary CARING does not model at all). Corrected 2026-09-06: the $ref to the CARING enum declared three live integrations non-conformant, and a rule that outlaws shipped correct behaviour is the rule that is wrong." }, "tenant": {"type": "string", "minLength": 1}, "attributes": {"type": "object", "additionalProperties": true} } }, "resource_ref": { "type": "object", "additionalProperties": false, "required": ["id"], "properties": { "id": {"type": "string", "minLength": 1}, "type": {"type": "string", "minLength": 1}, "system": {"type": "string", "minLength": 1}, "tenant": {"type": "string", "minLength": 1}, "attributes": {"type": "object", "additionalProperties": true} } } } }