3 posts tagged with "audit"

On August 12 we published a persistence baseline across six TeaQL runtimes and a nine-database Java matrix. That was useful evidence, but it was not the complete Order Search Feature.

The next acceptance run closed that distinction. Java, Rust, Go, Python, .NET and TypeScript each executed the generated Order Search API against PostgreSQL, MySQL and SQLite: 18 of 18 core cells passed, representing 252 successful positive dynamic scenario executions.

We refactored the TeaQL Java runtime (teaql-java) to achieve three goals:

1. JPMS module boundaries — seal internal packages, expose only what generated code needs
2. Spring Boot independence — run without Spring Boot using a plain main() function
3. Rust alignment — dual-layer audit logging, compile-time query enforcement, RequestPolicy

In the era of AI Coding, business code may be co-generated and modified by human developers, AI agents, or automated tools. This brings a new challenge:

While business logic is becoming increasingly easy to generate automatically, the audit chain must not become fragile as a result.

Traditional audit systems often rely on business code to actively record logs. However, in AI Coding scenarios, this approach carries clear risks:

• AI might forget to write audit logs;
• AI might accidentally disable logs;
• AI might generate code that bypasses audits;
• Business code might unintentionally record sensitive plain text;
• A custom audit hook might access raw data it shouldn't see;
• Long strings, JSON payloads, or execution logs might cause audit log bloating or even out-of-memory (OOM) errors.

Therefore, TeaQL underwent a low-level refactoring to move auditing capabilities into the framework kernel rather than leaving them entirely to the business code. We established the following core principles:

Audit must be kernel-level.
Business code may enrich audit trails, but it cannot erase them.
Sensitive fields do not disappear; only their plain text disappears.