AiNIR v1.0 RC Candidate uses a small public safety registry to classify effect families.
The public demo includes pattern-based safety-critical detection for known fixture families, but production systems should prefer canonical effect contracts over open-ended string guessing.
The public demo blocks known safety-critical patterns such as:
- irreversible financial-effect markers;
- unprotected PII markers;
- synthetic secret persistence markers;
- irreversible deletion markers;
- undeclared external/system-level effect markers.
This is enough for the bounded examples, but it is not a complete enterprise effect taxonomy.
A string classifier can never enumerate every possible spelling of a risky effect. A production path should avoid relying on terms like real, live, or production alone.
Production effect handling should move toward:
- canonical effect ids only;
- registry-declared effect families;
- operation specs that declare implied effect families;
- explicit aliases registered in the safety registry;
- unknown effect ids resolved as
review_requiredor refused; - signed or versioned registry snapshots.
The public repo demonstrates conservative effect and capability boundaries for a bounded demo. It does not claim to classify arbitrary enterprise effect names.
The public registry uses conservative patterns for the demo, but production should prefer canonical effect contracts over open-ended name inference. Unknown or alias-like effects should be refused or sent to review until the registry explicitly maps them to a family, risk class, evidence requirement, and capability contract.