# Determinant: A human-auditable deterministic layer between LLMs and code

> Source: <https://discuss.huggingface.co/t/determinant-a-human-auditable-deterministic-layer-between-llms-and-code/179238#post_1>
> Published: 2026-08-25 16:40:18+00:00

Most AI coding workflows are still probabilistic all the way from requirements to final implementation.

Even if a SPEC is extremely detailed and carefully written, the generated code may still differ because of a different model, different context, different memory, different tools, different context compression, or simply because the same task is run again at a different time.

I want to experiment with moving that boundary.

```
Natural language
→ LLM
→ AAL
→ Human review
════════════════════
→ Deterministic compilation
→ TypeScript / Node.js
```

AAL stands for **Auditable Application Language**.

Determinant does not try to make the LLM itself deterministic.

The same natural-language requirement may still produce different AAL when generated by different models, under different contexts, or with different tools.

That uncertainty does not disappear, because it is inherent to LLMs.

What Determinant tries to do is:

Contain that uncertainty inside a smaller, more human-auditable boundary, and make it stop there.

AI may generate and modify AAL, but once a human accepts the AAL, the compilation path no longer uses an LLM.

A very small AAL example:

```
application: InventoryApp

object: Inventory

    quantity: integer

flow: DeductInventory

    input:
        inventory: Inventory
        quantity: integer

    if inventory's quantity < quantity:
        failure: Insufficient inventory

    change:
        inventory's quantity = inventory's quantity - quantity

    output:
        remainingInventory = inventory's quantity
```

What the human needs to review is:

when inventory is considered insufficient;

whether the inventory is actually changed;

what the result is after that change.

The compiler is free to decide how this is implemented in TypeScript.

The human does not need to review the generated class structure, local variables, Promise usage, or other implementation details.

Once the AAL is accepted, the current compilation path is:

```
AAL
↓
Parser
↓
AST
↓
Semantic Check
↓
Binding
↓
Compiler
↓
TypeScript
↓
Node.js
```

This path does not call an LLM.

The intended boundary is:

```
same AAL
+ same language version and dialect
+ same Binding
+ same compiler version
+ same runtime and dependencies
= same program semantics
```

So Determinant does not eliminate uncertainty from AI-assisted development.

More precisely, it tries to:

Reduce the scope of uncertainty and give it an explicit endpoint.

A typical AI coding workflow looks more like:

```
Requirement
↓
AI
↓
Large amount of implementation code
↓
Human reviews code
```

Determinant experiments with:

```
Requirement
↓
AI
↓
Smaller, auditable AAL
↓
Human reviews behavior
↓
Deterministic compilation
↓
Implementation code
```

This idea is intentionally built on existing software engineering concepts such as DSLs, model-driven development, intermediate representations, and deterministic compilers.

I am not trying to reinvent DSLs or deterministic compilation.

The actual question I want to test is:

Can we move the deterministic boundary upward in AI coding?

In other words, let probabilistic AI produce a smaller, executable, human-auditable description, and once that description is accepted, move the rest of program generation back into traditional deterministic software engineering.

AAL currently keeps only two primary concepts:

```
Object
Flow
```

An Object describes what exists in the application world.

A Flow describes what happens in the application world.

The language tries to avoid exposing ordinary implementation structures such as classes, methods, `this`

, dot-based property access, or framework-specific calls, and instead focuses on business behavior, conditions, explicit state changes, and results.

There is also a separate Binding layer that connects human-facing audit names, stable internal identities, and program-facing names.

This lets AAL keep names that are easier for humans to review without forcing TypeScript, database, or external-system naming conventions directly into the audit language.

The current repository already contains a minimal deterministic compilation loop with:

Objects and typed fields

Flows

Conditions and explicit failures

Calculations

Explicit state changes

Flow composition

Explicit money types

Binding

English and Chinese AAL dialects

TypeScript code generation

Executable success and failure tests

The first target runtime is:

```
Node.js + TypeScript
```

HTTP and CRUD are planned as the next iteration and are not part of the current implementation yet.

GitHub:

This project is still a very early experiment.

The main question I want to test is simple:

If AI is already doing most of the implementation work, should humans still review hundreds or thousands of lines of AI-generated code line by line?

Or should human review move to a much smaller, executable language that explicitly describes what the software is allowed to do?

The core idea of Determinant can be summarized in one sentence:

Before review, AI may be probabilistic. After review, the software should not remain probabilistic.

Feedback and criticism are very welcome, especially around whether this review boundary is actually useful in practice, and whether AAL can remain readable while covering enough real application behavior.
