OPFiles and AIQT

OPFiles is a standalone standard, authored and maintained by Jeff Posluns and source-available under the Elastic License 2.0 (ELv2). It ships as part of AIQT: adopting AIQT brings OPFiles with it, and the planned assistant-driven adoption flow will also migrate your existing operational files into the store; reviewed manual import is available now through opf import --apply. OPFiles remains available on its own: AIQT Guardrails consumes and enforces the standard through one optional profile, and a base adopter need not adopt AIQT Guardrails at all.

The relationship

Jeff Posluns authors and maintains the standard. AIQT and AIQT Guardrails are his trademarks; 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.

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. The AIQT profile declares a posture floor of required, a set of required modules (governance, operational policy, and concurrent operation), a triple-family verification floor that base tools ignore, and its own x-aiqt record extension namespace. Where a profile setting meets a base setting, they combine toward the stricter value.

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.

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.

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. aiqt.ai maps to the repository root and opfiles.ai maps to the opf path, so the two sites are two views of one source, not two products maintained apart.

Adopting OPFiles is what lets the guardrails run on structured records: the TOML carries the input each process declares, which reduces ambiguity and the likelihood of errors, omissions, and hallucinations, and can reduce the inference and token spend that go into reconstructing context; net savings depend on the workflow and should be measured. Adopting AIQT brings the OPFiles store by default; an adopter can instead take just the guardrail rules without the OPFiles store, but that rules-only path misses these capabilities.

You can adopt OPFiles without AIQT

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