Update to Oximy Reality Checks

{
  "description": "Compare written AI policy with observed agent configuration and runtime evidence, producing a non-accusatory mismatch ledger. Use when someone wants to test whether approved tools, data rules, permissions, retention, review gates, or prohibited actions match practice. Do not use individual activity as a proxy for intent or misconduct.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 260
    },
    {
      "relative_path": "evals/cases.json",
      "size_in_bytes": 916
    },
    {
      "relative_path": "references/status-model.md",
      "size_in_bytes": 1034
    },
    {
      "relative_path": "scripts/validate_matrix.py",
      "size_in_bytes": 2211
    }
  ],
  "name": "policy-vs-reality",
  "skill_md_contents": "---\nname: policy-vs-reality\ndescription: Compare written AI policy with observed agent configuration and runtime evidence, producing a non-accusatory mismatch ledger. Use when someone wants to test whether approved tools, data rules, permissions, retention, review gates, or prohibited actions match practice. Do not use individual activity as a proxy for intent or misconduct.\nlicense: MIT\n---\n\n# Policy vs Reality\n\nTest policy statements at the enforcement point they imply. A document can be current while implementation is missing; configuration can be compliant while runtime conformance remains unobserved.\n\n## Boundary\n\n- Default to system, workflow, or cohort evidence. Name individuals only when the user explicitly requires it and the evidence and policy authorize that use.\n- Do not characterize a mismatch as misconduct. It may be policy ambiguity, stale documentation, configuration drift, an approved exception, or incomplete evidence.\n- Do not change policy, configuration, permissions, or records during the comparison.\n\n## Workflow\n\n1. Establish scope: policy version, effective date, covered population, environments, workflows, and observation window.\n2. Decompose the policy into atomic, testable statements. Separate requirements, prohibitions, approvals, exceptions, and aspirations.\n3. For each statement, name its expected enforcement or evidence point: identity provider, model gateway, endpoint, device policy, agent configuration, tool permission, log, review system, retention control, or human procedure.\n4. Inventory configuration and runtime evidence. Run `scripts/validate_matrix.py` after constructing the structured comparison matrix.\n5. Assign one status per statement: aligned, configured-not-observed, observed-not-documented, contradictory, exception, ambiguous-policy, or unknown.\n6. Distinguish collection, transmission, processing, storage, memory, display, reporting, and deletion. A control covering one does not silently cover the others.\n7. Determine the likely mismatch class without assigning blame: policy defect, documentation lag, control gap, implementation drift, exception-management gap, or evidence gap.\n8. Prioritize remediation by plausible harm, breadth, reversibility, and evidence strength. State the owner role and verification readback, not a person's name unless supplied.\n\nRead [references/status-model.md](references/status-model.md) before finalizing the matrix.\n\n## Completion criterion\n\nEvery in-scope policy statement is atomic and mapped to an evidence or enforcement point; every row has one status and an evidence pointer or explicit gap; lifecycle stages are not conflated; exceptions remain distinct from contradictions; and the output contains no unsupported allegation about individual behavior.\n\n## Output\n\n1. Scope and policy identity\n2. Coverage and evidence limitations\n3. Policy-to-reality matrix\n4. Mismatches by class, not by person\n5. Approved or unresolved exceptions\n6. Prioritized remediation with owner role\n7. Verification plan\n"
}