AlgoCompliance + Codex = AICompliance

Inspiration

AlgoCompliance already transforms regulations, SOPs, and internal policies into guided workflows, real-time validation, connected documents, and audit-ready records.

Its purpose is simple:

Transform what organizations must obey into the procedures their employees actually follow.

We have already applied this approach to projects involving hundreds of pages of rules and operating procedures. The next challenge is scale.

Large organizations may have hundreds of thousands or millions of pages of SOPs, internal controls, policies, work instructions, and operating manuals. Manually converting that material into executable compliance applications is not scalable.

The question that inspired this project was:

How can we transform 200,000 or even 2,000,000 pages of organizational procedures into executable compliance infrastructure?

We concluded that law itself is not the best starting representation. Law defines obligations, prohibitions, thresholds, and reporting requirements. It rarely defines the complete company-specific process: who acts, which system they use, what data they enter, who approves the action, which exceptions apply, and what evidence must be retained.

The appropriate starting point is the organization’s SOP.

What it does

AICompliance introduces an intermediate representation called SOP*.

The architecture is:

SOP → SOP* → Iolex → AlgoCompliance

Each layer serves a different purpose:

Representation	Lawyer-readable	Computable	Executable
Natural-language SOP	Yes	Limited	No
SOP*	Yes	Yes	No
Iolex	Limited	Yes	Yes
AlgoCompliance	Operational interface	Yes	Running system

Natural-language SOPs are readable but difficult to analyze computationally. They may contain contradictions, missing approvals, circular procedures, unreachable steps, inconsistent thresholds, or control-avoidance paths.

Iolex, our executable domain-specific language, is highly computable but too detailed for efficient lawyer-led review.

SOP* occupies the necessary middle layer. It is concise enough for lawyers to review and formal enough for computers to analyze.

We currently represent SOP* using canonical Prolog predicates such as:

choice(Actor, Decision, Options).

comply(Condition, Actor, Obligation).

What existed before Build Week

Before Build Week, the following components already existed:

• AlgoCompliance;
• AlgoFlow;
• DSAT;
• Connected Documents;
• the Iolex domain-specific language;
• the ability to transform Iolex into a running compliance application;
• a human-led process for converting SOPs into Iolex.

Build Week focused on the missing translation, testing, and interpretability layers needed to scale that architecture.

What we built with Codex

1. Iolex-derived replay testing

Codex read formalized Iolex validation rules and created an application-specific Playwright replay suite.

The demonstration covers 13 positive and negative scenarios. The replay scripts verify whether:

• the correct fields appear;
• validation rules activate under the correct conditions;
• valid cases are accepted;
• invalid cases are blocked;
• planning and actual-report values transfer correctly;
• error paths behave as designed.

All 13 recorded scenarios passed.

This makes executable compliance logic testable as well as operational.

2. AlgoCompliance2SOPStar

Codex created a unified reverse-translation prototype covering the three principal layers of an AlgoCompliance application:

AlgoFlow → SOP*
DSAT → SOP*
Connected Documents → SOP*

The sample application was translated into:

Source layer	SOP* facts
AlgoFlow	264
DSAT	2,411
Connected Documents	429
Total	3,104

The combined rulebook contains:

• 186 choice/3 facts;
• 2,918 comply/3 facts.

This gives lawyers and compliance professionals a computable description of what the running application actually does.

3. Codex as an Iolex Whisperer

Codex also served as a natural-language interface to Iolex.

In the demonstration, Codex traced legacy-value propagation across planning and actual-report documents. It identified the real source fields, initialized missing keys, rejected contaminated values, introduced safer fallbacks, and generated defensive Iolex corrections.

This workflow connected:

Natural-language instruction
→ code diagnosis
→ Iolex modification
→ regression testing

4. Forward SOP-to-SOP* translation

The final component is the forward translator:

Natural-language SOP → SOP*

It extracts operational concepts such as:

• actors;
• actions;
• decisions;
• conditions;
• approval thresholds;
• exceptions;
• required data;
• evidence requirements;
• deadlines;
• unresolved ambiguities.

The forward translator uses the same canonical SOP* predicates as the reverse translator.

This enables two independent paths to converge:

Natural-language SOP → Forward SOP*

Running application → Reverse SOP*

The two representations can then be compared to identify:

• SOP requirements missing from the application;
• application behavior not documented in the SOP;
• contradictory procedures;
• naming differences;
• unresolved ambiguities;
• implementation-specific legacy behavior.

How we built it

Codex was used as the primary implementation partner throughout the Build Week work.

It helped us:

• inspect the existing Iolex and AlgoCompliance structures;
• identify translation boundaries;
• create Python translators;
• generate Playwright replay scripts;
• normalize multiple application layers into one SOP* ontology;
• create manifests and validation reports;
• diagnose legacy implementation defects;
• generate test evidence;
• prepare repository documentation and submission materials.

We used GPT-5.6 for architecture, representation design, adversarial review, narrative development, and evaluation of the claims against the available evidence.

The principal human design decisions were:

1. starting from SOP rather than law;
2. introducing SOP* as an intermediate representation;
3. requiring the forward and reverse translators to use the same ontology;
4. preserving lawyer review as the final authority;
5. treating ambiguity as an explicit output rather than allowing the model to invent missing logic.

Challenges

Choosing the correct representation

Natural language is too ambiguous for reliable computation. Iolex is too low-level for efficient expert review.

The main architectural challenge was designing a representation that is both computable and lawyer-readable.

Preserving meaning across layers

The same procedure must retain its meaning across:

SOP → SOP* → Iolex → AlgoCompliance

Roles, conditions, thresholds, exceptions, state transitions, and evidence requirements must not change silently during translation.

Working with legacy applications

Existing applications contain historical field names, fallback logic, formatted values, and planning-to-actual mappings. Codex had to trace how values propagated through the system before proposing safe corrections.

Distinguishing defects from intentional exceptions

A circular procedure, inconsistent condition, or unusual approval path may be an error, a deliberate exception, or a legacy business requirement.

AICompliance surfaces the issue. Lawyers and compliance officers remain responsible for determining its meaning.

Protecting confidential information

The production application contains confidential client and operational information.

The public or judging package therefore uses sanitized demonstration inputs. Production-scale performance is represented through sanitized manifests, validation reports, and selected output samples.

What we learned

Scale is a representation problem

The main obstacle is not placing more pages into a larger context window.

The obstacle is transforming organizational knowledge into representations through which humans and machines can reason reliably.

The intermediate representation is the key asset

SOP* creates the layer where legal review and machine computation can meet.

Forward generation is not enough

A trustworthy system also needs:

• reverse translation;
• provenance;
• ambiguity reporting;
• structural analysis;
• replay testing;
• semantic comparison.

Tests should travel with the procedure

An executable compliance procedure should be accompanied by evidence that it behaves as designed.

Replay tests therefore belong to the generated compliance asset.

Human authority must remain explicit

Codex can extract, translate, explain, diagnose, and propose corrections.

It should not silently resolve missing or ambiguous compliance logic. Those issues must be surfaced for expert determination.

Accomplishments

During Build Week, we demonstrated:

• an Iolex-derived replay suite with 13 of 13 recorded scenarios passing;
• a unified AlgoCompliance-to-SOP* prototype;
• reverse translation of one application into 3,104 SOP* facts;
• workflow, data, validation, and document-dependency extraction;
• Codex-assisted Iolex diagnosis and repair;
• forward translation from natural-language SOP into the same SOP* representation;
• the basis for comparing what an SOP says with what an application actually does.

What comes next

The next milestones are:

1. expand SOP2SOPStar across longer and more diverse SOPs;
2. add source-level citations to every generated fact;
3. detect contradictions, closed loops, unreachable steps, missing approvals, and control-avoidance paths;
4. complete SOPStar2Iolex;
5. implement semantic round-trip testing;
6. create a lawyer-facing SOP* review interface;
7. measure extraction accuracy, correction rate, test coverage, and transformation cost;
8. run staged enterprise pilots across complete SOP libraries.

Conclusion

Rules tell organizations what to obey.

SOPs describe how the organization intends to obey.

SOP* makes the procedure computable and lawyer-readable.

Iolex makes it executable.

AlgoCompliance makes it operational.

Codex makes the transformation scalable.

Built With

• c#
• codex
• javascript
• python