AI Governance & Audit

AI-generated code needs enforceable interfaces and repeatable verification, not only prompt instructions. TeaQL supplies several useful typed boundaries, but it does not make every line authorized, audited, or safe automatically.

Current evidence boundary: Rust 4.1.1 generated queries expose execution after comment → purpose; generated persistence uses audit_as with AuditedSave; and teaql-tool-core 1.0.0 contains a generic MustPurpose<T> wrapper plus audit configuration types. These contracts do not sandbox arbitrary Rust or prove sink completeness.

Compiler-Enforced Boundaries That Are Verified

Surface	Verified constraint	Remaining review
Generated query	Execution is exposed on a purposed query after comment(...) and purpose(...).	Purpose truthfulness, authorization, query cost, and provider behavior.
Generated mutation	Persistence uses an audit description through audit_as(...).	Approval, transaction scope, event delivery, masking, and retention.
Generic purpose wrapper	MustPurpose<T> keeps its value private until purpose(...) consumes the wrapper.	Which application/tool APIs actually return the wrapper.
Generated API surface	Model-derived methods make many invalid names fail compilation.	Business correctness and generated-method inspection.

Earlier examples described a universal MustComment<T> wrapper around every computation and I/O operation. That universal mapping is not established by the released/generated sources inspected here. Do not assume an arbitrary network, file, command, time, or third-party call is wrapped.

Compilation Is One Gate, Not Authorization

Compilation can catch unavailable generated methods and missing typestate transitions. It cannot determine whether:

• the caller owns the object;
• a tenant filter covers every path;
• the stated business purpose is truthful;
• a query is affordable under production load;
• a mutation has the required human approval;
• an audit sink is durable or tamper-resistant;
• a dependency or handwritten path bypasses generated APIs.

Authorization and tenant policy must be registered and tested in the application runtime. Human review remains necessary for model changes, generated diffs, policy, migrations, dependencies, and infrastructure.

Project-Owned Static Restrictions

A project may configure Clippy to reject selected types or methods and may use dependency allowlists to narrow handwritten code. These controls are useful, but they are not automatically supplied as a complete TeaQL sandbox.

Verify:

• which workspace crates run the lint;
• whether warnings fail CI;
• allowed exceptions and allow attributes;
• direct and transitive dependencies;
• generated-code treatment;
• operating-system/container network, file, and process permissions.

Static restrictions complement runtime least privilege; they do not replace it.

Runtime Audit Configuration

Current generated workspaces read audit, SQL, tool, sink, and schema settings from environment variables through teaql-tool-core. The current verified contract is documented in Environment Variables.

Configuration changes output detail; they do not guarantee that all operations emit records or that records reach protected storage. Test subscriber/sink initialization, payload redaction, delivery failure, transaction timing, retention, access, and deletion.

Do not copy unverified programmatic builders such as hypothetical AuditConfig::production() or capability methods from positioning examples. Read the released crate and generated workspace used by the project.

Governed AI Change Loop

Model or handwritten change
  -> evaluate and read the Markdown report
  -> regenerate
  -> review generated diff and exact methods
  -> compile and run contract checks
  -> run authorization/query/mutation/provider tests
  -> inspect redacted runtime evidence
  -> human approval

For queries, reviewers require comment → purpose → execution. For mutations, reviewers require audit_as before persistence. A passing chain only proves that the declared contract is present; the test suite must prove the intended business and security behavior.

Evidence to Retain

• model revision and evaluator report;
• generator, client, runtime, provider, database, and toolchain versions;
• generated diff and dependency manifests;
• compile/test results;
• positive and negative authorization tests;
• query and audited-mutation probes;
• sink/masking/failure evidence with sensitive values redacted;
• reviewer and release decision.

Use Rust Agent Tool Boundary for the versioned API boundary, Security and Trust Boundaries for application responsibilities, and Human Review Gate for approval criteria.