OPFiles and AIQT

OPFiles is a standalone standard, authored and maintained by Jeff Posluns; AIQT Guardrails consumes and enforces it through one optional profile, so adopting AIQT brings OPFiles, yet a base adopter need not adopt AIQT at all.

The relationship

Jeff Posluns authors and maintains the standard. AIQT and AIQT Guardrails are his trademarks (registration pending), and AIQT is a brand, not a legal entity; the standard's formal name, the AIQT Development Operational Standard, uses the AIQT trademark. AIQT Guardrails ships [profiles.aiqt] as one reference profile, but the pack is a consumer, not the definition. The base standard is the [opf] table and its rules; base-only tooling reads and validates the base and operates on it alone. AIQT Guardrails' own requirements ride the profile, and nothing in the base vocabulary names AIQT or any other adopter.

The profile

What the profile adds

A profile may only add requirements; it can never weaken, remove, or override a base requirement, and a profile value that would loosen a base setting is a profile validation failure, surfaced, never applied. Where a profile setting meets a base setting, they combine toward the stricter value.

Posture floor

A floor of required.

Required modules

Governance, operational policy, and concurrent operation.

Verifier-diversity floor

A reference-suite policy the AIQT profile declares as verification_floor = "triple-family": verify a change with three model families. Base tools ignore it; it is a discipline adopters follow, not machinery OPFiles runs for you.

The `x-aiqt` namespace

Its own record extension namespace.

profile example

[opf]            # the base standard: rules every adopter follows

[profiles.aiqt]  # one optional profile: may only add, never loosen
posture_floor = "required"

Illustrative: the base [opf] table is what every adopter follows; the [profiles.aiqt] table only tightens it.

Tool behaviour

How tools treat the profile

A tool that does not recognize a declared profile, or does not support its major version, ignores it for enforcement and records it as present-but-unevaluated; it does not fail base validation over an unknown profile. A tool that does support the profile enforces its extra requirements as additional gates and fails closed on an unreadable, unparseable, or base-incompatible instance of it. Fail-safe governs a profile outside a tool's coverage; fail-closed governs a profile inside it.

Inheritance

Adopt AIQT and you inherit OPFiles

The records-first discipline AIQT Guardrails enforces is one implementation of this standard, so by default an AIQT adopter is an OPFiles adopter. If you arrived from aiqt.ai, the store and release model described across this site is the same one the pack works.

On the assistant-driven adoption path, include existing operational files in the reviewed adoption plan. Clean-start adoption is the intake; the ordinary opf import modes are retired, and post-adoption import will use the approved prompt pack.

One source

One repository, two entry points

A single repository, github.com/jposluns/guardrails, holds both. Its root is AIQT, which includes OPFiles, and standalone OPFiles lives at the opf path within it. This site documents the OPFiles subtree; the AIQT site documents the suite.

OPFiles provides structured TOML inputs for record-aware checks. The intended benefits include less ambiguity, fewer errors and omissions, and less context reconstruction. This page supplies no observed evaluation of those effects or of hallucination rates or token savings; measure them in your workflow. The AIQT adoption path includes OPFiles by default. Taking only the guardrail rules does not create an OPFiles store or run its record checks.

Standalone

You can adopt OPFiles without AIQT

The profile is optional. A base adopter can align with the specification using their own checks, or the reference tooling, and need not enable [profiles.aiqt] at all. See adopt by hand for the neutral, tooling-independent path.