DDAC

Decoupled Divergence and Adversarial Convergence
A research-oriented architecture for independent exploration, provenance-controlled evaluation, and interruption-resilient software development.

Status · Architecture · Codex Desktop · Scientific positioning · Evaluation · Roadmap

Overview

DDAC is a staged human–AI software-engineering framework for problems where the first plausible answer is not necessarily the best answer.

It separates three operations that are commonly collapsed into one conversational loop:

Divergence — generate meaningfully different candidate mechanisms without cross-branch anchoring.
Adversarial convergence — evaluate normalized candidates against evidence, constraints, failure modes, and reversibility.
Scaffolded execution — convert the selected approach into small, testable, resumable actions.

DDAC is designed around a simple premise:

Reliable reasoning depends not only on model capability, but on when information is shared, what crosses each boundary, how claims are evaluated, and how decisions become executable work.

This repository is intended to be Codex Desktop native. It includes repository-level AGENTS.md instructions, execution-plan conventions, local Codex skills, machine-readable schemas, and documentation that lets multiple isolated Codex threads work on the same project without silently collapsing into one shared line of thought.

Status

Phase 1 reference implementation — runnable, testable, and still not a validated scientific result.

The repository now includes:

a zero-dependency Python 3.11+ orchestrator;
a native codex exec provider adapter;
deterministic offline demo mode;
isolated branch workspaces with explicit context allowlists;
runtime schema validation and budgeted repair;
provenance-blind normalization and private audit mapping;
hard budgets, cancellation, quarantine, manifests, and JSONL events;
a complete convergence pass and Execution Capsule;
automated tests and CI.

It does not yet establish that DDAC improves coding accuracy, developer productivity, creativity, or outcomes for people with ADHD. Those are testable hypotheses, not settled conclusions.

Quick start

No package installation or API key is required for the deterministic pipeline demo:

git clone https://github.com/JinParkmida/DDAC.git
cd DDAC
python -m ddac doctor
python -m ddac demo

The command writes a complete run under .ddac/runs/, including:

branch artifacts;
normalized blind candidates;
private provenance;
eligibility decisions;
mechanism clusters;
adversarial evaluations;
a complementary portfolio;
the current Execution Capsule;
SUMMARY.md;
manifest.json;
events.jsonl.

The mock provider verifies orchestration, isolation, schemas, artifacts, and failure handling. It does not simulate model quality.

Run with Codex

Install and authenticate the Codex CLI, then run:

python -m ddac run \
  --problem examples/payment-idempotency/problem-contract.json \
  --provider codex \
  --branches 5 \
  --candidates-per-branch 2

Give divergence branches repository context explicitly:

python -m ddac run \
  --problem path/to/problem-contract.json \
  --provider codex \
  --project-root . \
  --context src \
  --context tests \
  --seed 42

Context is copied into separate branch workspaces. Branches do not receive one another's output directories.

Optional editable installation exposes the shorter ddac command:

python -m pip install -e .
ddac demo

Run checks with:

python scripts/validate_repo.py
python -m unittest discover -s tests -v

Why DDAC exists

Autoregressive systems are excellent at extending a plausible trajectory. That same property can make them vulnerable to premature commitment:

early candidate ideas become anchors;
later alternatives become paraphrases rather than independent mechanisms;
a generator may defend assumptions embedded in its own proposal;
multi-agent discussion can produce correlated confidence rather than independent evidence;
long shared contexts accumulate rhetorical and irrelevant state;
implementation can begin before the problem, constraints, and acceptance tests are stable.

For developers, the problem is not only solution quality. Complex coding work also creates a large state-management burden: unresolved decisions, hidden assumptions, interrupted work, uncertain next actions, and expensive context reconstruction.

DDAC addresses both levels:

epistemic architecture for the AI system;
execution scaffolding for the human–AI workflow.

Design goals

DDAC aims to:

preserve independent search long enough to discover genuinely different mechanisms;
prevent origin, confidence, style, and branch identity from biasing evaluation;
require critics to expose causal failure mechanisms rather than vague objections;
prefer evidence and reversible experiments over confident speculation;
select a portfolio of complementary options instead of near-duplicate top scores;
reduce implementation activation energy;
preserve enough state to resume after interruption;
make every scientific and engineering claim auditable.

DDAC does not aim to:

maximize the number of agents;
simulate personalities for entertainment;
replace testing, measurement, code review, or domain expertise;
diagnose or treat ADHD;
claim novelty merely because similar work uses different terminology;
hide uncertainty behind a polished multi-agent workflow.

Architecture

System model

flowchart LR
    P[Problem statement] --> S0[Stage 0<br/>Problem Stabilization]
    S0 --> C[Problem Contract]

    C --> D1[Isolated Branch A]
    C --> D2[Isolated Branch B]
    C --> D3[Isolated Branch C]
    C --> DN[Isolated Branch N]

    D1 --> N[Stage 2<br/>Provenance-Blind Normalization]
    D2 --> N
    D3 --> N
    DN --> N

    N --> E[Stage 3<br/>Adversarial Convergence]
    E --> G[Eligibility gate]
    G --> K[Mechanism clustering]
    K --> R[Red-team evaluation]
    R --> PSEL[Portfolio selection]

    PSEL --> X[Stage 4<br/>Scaffolded Execution]
    X --> EC[Execution Capsule]
    EC --> T[Test / Observe]
    T -->|evidence changes| S0
    T -->|validated| O[Accepted result]

Stage 0 — Problem Stabilization

Divergence is wasteful when every branch solves a different problem. DDAC therefore begins with a Problem Contract.

The contract records:

objective;
current and expected behaviour;
known evidence;
constraints;
unknowns;
acceptance tests;
decision cost;
reversibility;
safety boundaries.

Example:

{
  "objective": "Prevent duplicate payment capture during retry storms",
  "current_behavior": "A retried request can create more than one capture",
  "expected_behavior": "One logical payment produces at most one capture",
  "constraints": [
    "No breaking API change",
    "Must tolerate worker restarts"
  ],
  "known_evidence": [
    "Duplicate captures share the same client operation ID"
  ],
  "unknowns": [
    "Whether the gateway idempotency window is sufficient"
  ],
  "acceptance_tests": [
    "100 concurrent retries produce one capture"
  ],
  "decision_cost": "high",
  "reversibility": "moderate"
}

The JSON Schema is in schemas/problem-contract.schema.json.

Gate

If the available evidence cannot distinguish plausible causes, DDAC should generate diagnostic experiments, not architectural solutions.

Stage 1 — Context-Isolated Divergence

The orchestrator creates multiple independent branches. Each branch receives:

the same Problem Contract;
one functional search frame;
the same output schema;
no candidate generated by another branch;
no emerging ranking or consensus signal.

A branch produces one or more Candidate Mechanisms.

flowchart TB
    PC[Problem Contract]
    PC --> F1[Minimum-change frame]
    PC --> F2[First-principles frame]
    PC --> F3[Failure-containment frame]
    PC --> F4[Observability-first frame]
    PC --> F5[External-domain analogy]

    F1 --> C1[Candidate records]
    F2 --> C2[Candidate records]
    F3 --> C3[Candidate records]
    F4 --> C4[Candidate records]
    F5 --> C5[Candidate records]

Functional frames, not theatrical personas

A useful frame changes at least one of:

optimization target;
permitted assumptions;
intervention layer;
failure tolerance;
evidence standard;
resource budget;
reversibility requirement.

Examples:

Frame	Search constraint
Minimum-change repair	Preserve interfaces and minimize changed surface area
First-principles redesign	Ignore current decomposition; preserve only required invariants
Failure containment	Assume components fail and limit blast radius
Observability first	Prefer interventions that first improve causal visibility
Resource constrained	Optimize under explicit latency, memory, cost, or staffing limits
Adversarial security	Search for bypasses, confused-deputy paths, and unsafe defaults
Reversible experiment	Prefer the smallest intervention that reduces decisive uncertainty
External-domain analogy	Import a mechanism from a structurally related domain

A metaphor may inspire a frame, but the implemented constraint must remain inspectable.

Candidate contract

A candidate is not a slogan. It must include enough information for technical evaluation:

{
  "mechanism": "Persist an idempotency record before gateway submission",
  "causal_model": "All retries converge on one durable operation state",
  "assumptions": [
    "The operation ID is stable across retries"
  ],
  "required_changes": [
    "Create an operation table with a unique key"
  ],
  "predicted_observations": [
    "Concurrent retries return the same operation result"
  ],
  "falsification_test": "Kill the worker after persistence and before submission",
  "estimated_scope": "medium",
  "uncertainties": [
    "Gateway reconciliation after ambiguous timeout"
  ]
}

See schemas/candidate.schema.json.

Stage 2 — Provenance-Blind Normalization

The boundary between generation and evaluation is an information-control layer, not indiscriminate deletion.

The normalizer removes information that should not influence technical judgment:

branch identity;
frame name;
model identity;
confidence rhetoric;
self-praise;
stylistic elaboration;
unsupported novelty claims;
references to competing candidates.

It preserves information required for evaluation:

mechanism;
causal model;
assumptions;
dependencies;
required changes;
predicted observations;
falsification tests;
uncertainty.

It then:

validates the schema;
splits compound proposals;
merges exact duplicates;
assigns randomized evaluation IDs;
records a private provenance map for later audit;
passes only normalized candidates to critics.

flowchart LR
    R[Raw candidate] --> V[Schema validation]
    V --> S[Semantic normalization]
    S --> D[Duplicate and compound handling]
    D --> I[Randomized evaluation ID]
    I --> B[Blind evaluation payload]

    R -. private audit map .-> A[(Provenance store)]

This design avoids two opposite errors:

letting rhetorical origin bias the critic;
stripping so much context that a critic cannot assess the mechanism.

Stage 3 — Adversarial Convergence

Convergence is a sequence of explicit gates, not one unconstrained “choose the best” prompt.

Pass A — Eligibility

A candidate is ineligible when it:

contradicts the Problem Contract;
depends on unavailable capabilities;
cannot be operationalized or tested;
merely restates the desired outcome;
violates a safety boundary;
duplicates another candidate without material difference.

Pass B — Mechanism clustering

Eligible candidates are grouped by causal mechanism rather than vocabulary.

Possible clusters include:

state and consistency;
concurrency control;
queueing and backpressure;
caching and locality;
observability;
protocol and API contracts;
algorithm substitution;
operational workflow.

Clustering prevents a shortlist from being filled with superficial variants of one idea.

Pass C — Constraint-conditioned evaluation

DDAC does not use one globally fixed score formula.

Each evaluation records:

expected utility;
feasibility;
evidence strength;
reversibility;
implementation burden;
diversity contribution;
unresolved uncertainty.

A generic utility model is:

[ U(c)= w_eE_c + w_fF_c + w_sS_c + w_rR_c + w_dD_c - w_bB_c - w_uU_c ]

The weights are derived from the Problem Contract. A security incident, exploratory prototype, and irreversible migration should not value novelty, reversibility, and burden in the same proportions.

Pass D — Mechanistic red team

A rejection must identify more than a negative adjective.

{
  "candidate_id": "eval-7f31",
  "strongest_failure_case": "Two workers create separate gateway requests",
  "violated_assumption": "The uniqueness check and submission are atomic",
  "failure_chain": [
    "Both workers observe no completed operation",
    "Both submit to the gateway",
    "Only one local record wins"
  ],
  "earliest_detection_signal": "Two gateway request IDs for one operation ID",
  "mitigation": "Claim the operation with a durable state transition before submission",
  "classification": "repairable",
  "residual_risk": "Ambiguous timeout still requires reconciliation"
}

The critic distinguishes:

fatal contradiction;
repairable defect;
uncertainty requiring an experiment;
trade-off requiring human choice.

See schemas/evaluation.schema.json.

Pass E — Portfolio selection

DDAC selects a complementary portfolio, not simply the three highest scalar scores.

The default portfolio contains:

Primary candidate — strongest expected utility under current evidence.
Reversible probe — smallest experiment that reduces the most consequential uncertainty.
Orthogonal alternative — strongest candidate using a genuinely different mechanism.
Frontier candidate — unconventional but feasible and evidence-bearing.

The frontier position is optional. Novelty alone is not a qualification.

Stage 4 — Scaffolded Execution

A selected architecture is not yet executable work.

DDAC converts the next unit of implementation into an Execution Capsule:

{
  "current_goal": "Reproduce the duplicate capture race",
  "definition_of_done": "A deterministic test creates two gateway submissions",
  "first_action": "Add a fake gateway that blocks after request receipt",
  "files_or_components": [
    "tests/payments/idempotency.test.ts"
  ],
  "validation_command": "pnpm test -- idempotency",
  "expected_result": "The new test fails with two recorded submissions",
  "stop_condition": "Do not modify production code before the failure is reproduced",
  "rollback_instruction": "Delete the test fixture and fake gateway",
  "restart_note": "The next step is to add durable operation claiming"
}

See schemas/execution-capsule.schema.json.

After each capsule, the workflow records:

what changed;
what was tested;
what happened;
what remains uncertain;
the exact next action.

This makes interruption recovery a first-class architectural concern.

Codex Desktop native

DDAC is designed to work with the Codex app’s project, thread, and worktree model.

Codex can load repository instructions from AGENTS.md, discover repository skills under .agents/skills, and use isolated worktrees for parallel agents. Official OpenAI documentation describes these mechanisms and recommends repository-local instructions and execution plans for long-running engineering work.

This repository contains:

DDAC/
├── AGENTS.md
├── PLANS.md
├── pyproject.toml
├── Makefile
├── ddac/                    # Phase 1 reference orchestrator
├── tests/                   # Unit and end-to-end tests
├── .agents/
│   └── skills/
│       ├── ddac-diverge/
│       │   └── SKILL.md
│       └── ddac-converge/
│           └── SKILL.md
├── docs/
├── schemas/
└── scripts/

Native orchestrator

Codex Desktop can invoke the repository CLI directly:

Run `python -m ddac doctor`, then use the DDAC orchestrator with the current
Problem Contract and explicitly allowlisted source paths. Show me SUMMARY.md
and the current Execution Capsule when it completes.

Under the hood, the Codex adapter uses non-interactive codex exec with an output schema, an ephemeral session, a read-only sandbox, and an isolated workspace for each model request.

Recommended Codex Desktop workflow

1. Open the repository as a Codex project

Codex reads AGENTS.md as the project-level operating agreement.

2. Stabilize the problem in one thread

Prompt:

Use the DDAC problem-stabilization protocol.
Create or update a Problem Contract for this task.
Do not propose implementation changes yet.

3. Launch independent divergence threads

Create separate Codex threads or worktrees. Assign one functional frame to each.

Example thread prompts:

Use the ddac-diverge skill.
Frame: minimum-change repair.
Read the same Problem Contract.
Do not inspect candidate files produced by other branches.
Write your candidate records to artifacts/divergence/minimum-change.json.

Use the ddac-diverge skill.
Frame: failure containment.
Read the same Problem Contract.
Do not inspect candidate files produced by other branches.
Write your candidate records to artifacts/divergence/failure-containment.json.

Codex worktrees provide filesystem isolation for parallel approaches. DDAC still requires procedural isolation: branches must not read one another’s candidate artifacts before the normalization step.

4. Normalize and evaluate in a fresh thread

Prompt:

Use the ddac-converge skill.
Validate and normalize all candidate records.
Hide branch and frame provenance during evaluation.
Produce an eligibility report, mechanism clusters, red-team analyses,
and a complementary candidate portfolio.
Do not implement any candidate yet.

5. Create an ExecPlan for substantial work

For a complex feature or refactor, follow PLANS.md. The plan remains a living record of decisions, tests, evidence, and progress.

6. Execute one capsule at a time

Prompt:

Implement only the current Execution Capsule.
Run its validation command.
Record the observed result and exact restart note.
Stop at the capsule's stop condition.

Why Codex Desktop is a natural fit

The Codex app supports:

separate task threads;
isolated worktrees;
diff review;
repository-local instructions;
local reusable skills;
long-running implementation plans.

These features supply the mechanical substrate DDAC needs. DDAC adds the epistemic protocol: which threads may share information, when convergence is permitted, and how evidence is carried into implementation.

Adaptive control

More branches do not guarantee better results.

DDAC continues divergence only while the expected improvement exceeds its added cost:

[ \mathbb{E}[\Delta Q_{t+1}] > \lambda C_{t+1} ]

where:

(\Delta Q_{t+1}) is expected improvement in portfolio quality;
(C_{t+1}) is additional compute, latency, and human-review cost;
(\lambda) represents task sensitivity to those costs.

Practical stopping signals:

no new mechanism cluster appears;
semantic and causal redundancy rises;
new branches repeat the same assumptions;
one candidate remains robust across reasonable evaluation weights;
the next useful action is a discriminating experiment.

ADHD-sensitive design

DDAC was motivated in part by coding workflows in which working-memory load, initiation friction, unbounded exploration, task switching, and interruption recovery can become costly.

The framework therefore adopts neuroinclusive interaction principles:

one explicit mode at a time: define, explore, choose, implement, test, record;
visible problem and execution state;
bounded next actions;
observable definitions of done;
restart notes after every action;
user-controlled candidate count and display density;
non-punitive replanning;
preserved human decision authority.

DDAC does not claim that every person with ADHD has the same needs. It does not diagnose or treat ADHD. Any claim that it improves outcomes for developers with ADHD requires direct participatory and controlled evaluation.

Scientific positioning

DDAC is not based on a claim that no one has previously separated generation from evaluation, used multiple agents, assigned perspectives, or performed adversarial critique. Those ideas have broad precedents across creativity research, design cognition, ensemble methods, multi-agent systems, verification, and human–computer interaction.

The research contribution under investigation is the specific system of boundaries and interfaces:

a stable shared Problem Contract;
context-isolated candidate generation;
functional search-frame variation;
provenance-blind semantic normalization;
evidence-bearing candidate records;
mechanistic adversarial evaluation;
diversity-aware portfolio selection;
bounded, resumable execution;
explicit claims and non-claims;
component-level empirical evaluation.

Recent literature supports treating LLM ideation as a novelty–validity trade-off, viewing reliability as an architectural property, separating planning and execution in coding agents, preserving human agency through structured friction, and designing AI task support around nonlinear attention and social or emotional scaffolding. The literature does not, by itself, validate DDAC.

Selected research context

LLM-based scientific ideation must balance novelty with scientific soundness, and current methods span distributional steering, inference-time scaling, knowledge augmentation, and multi-agent collaboration. (Shahhosseini et al., 2025)
Agent reliability increasingly depends on componentization, typed interfaces, validation, provenance, budgets, termination conditions, and assurance loops rather than model fluency alone. (Nowaczyk, 2025)
Terminal-native coding-agent research has explored separating planning from execution and controlling context growth in long-horizon software work. (Bui, 2026)
Structured visual and intermediate reasoning representations can support reflection, curation, and human creative agency in human–LLM design work. (Wang et al., 2025)
Adults with ADHD report task-management needs that are relational, affective, and nonlinear, suggesting that AI support should not assume constant self-regulation or purely linear task lists. (Chen et al., 2026)

See docs/research-positioning.md and docs/claims-and-evidence.md.

Formal hypotheses

DDAC is organized around falsifiable hypotheses.

ID	Hypothesis
H1	Context-isolated generation produces greater mechanism diversity than shared-context sequential generation under a matched budget.
H2	Provenance-blind evaluation reduces preference caused by confidence, branch order, model identity, or frame prestige.
H3	Evidence-bearing candidate records improve critic calibration compared with scoring short idea labels.
H4	Mechanistic red-team reports reduce false rejection of repairable candidates and false acceptance of hidden dependency failures.
H5	Diversity-aware portfolio selection is more robust than scalar top-(K) ranking on ambiguous engineering tasks.
H6	Execution Capsules reduce restart time and abandoned implementation paths compared with unstructured conversational assistance.
H7	Benefits exceed costs primarily for ambiguous, consequential, or difficult-to-reverse tasks.
H8	Developers reporting greater executive-function difficulty benefit more from visible state and interruption-recovery support, subject to individual variation.

Evaluation

Architecture study

Compare:

single-pass response;
token-matched single-agent ideation;
independent unframed sampling;
shared-context framed sampling;
isolated framed sampling;
isolated generation with non-blind criticism;
complete DDAC.

Task families:

repository-level debugging;
architecture design;
performance diagnosis;
security analysis;
migration planning;
ambiguous requirements.

Primary measures:

hidden-test success;
defect rate;
mechanism diversity;
assumption diversity;
correlated failure;
calibration;
invalid dependency count;
reversibility;
token and latency cost.

Human workflow study

Use a randomized crossover design comparing ordinary AI coding assistance with DDAC.

Measures:

completion rate;
time to first discriminating test;
abandoned solution paths;
interruption-recovery time;
unplanned context switches;
perceived cognitive load;
frustration;
perceived control;
trust calibration;
code quality.

Required ablations

Remove one component at a time:

Problem Contract;
branch isolation;
functional frames;
provenance-blind normalization;
evidence-bearing candidate schema;
mechanistic red team;
portfolio selection;
Execution Capsule;
restart state.

A framework-level improvement without ablation evidence is insufficient to identify the causal contribution.

Repository map

.
├── README.md
├── AGENTS.md
├── PLANS.md
├── CITATION.cff
├── CONTRIBUTING.md
├── CODE_OF_CONDUCT.md
├── SECURITY.md
├── LICENSE
├── .agents/
│   └── skills/
│       ├── ddac-diverge/SKILL.md
│       └── ddac-converge/SKILL.md
├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── architecture.yml
│   │   └── research.yml
│   ├── workflows/ci.yml
│   └── pull_request_template.md
├── docs/
│   ├── architecture.md
│   ├── claims-and-evidence.md
│   ├── research-positioning.md
│   ├── terminology.md
│   ├── plans/phase-1-reference-orchestrator.md
│   └── decisions/
│       ├── 0001-documentation-first.md
│       └── 0002-zero-dependency-python-orchestrator.md
├── examples/
│   └── payment-idempotency/
│       ├── problem-contract.json
│       ├── candidate.json
│       └── execution-capsule.json
├── schemas/
│   ├── problem-contract.schema.json
│   ├── candidate.schema.json
│   ├── evaluation.schema.json
│   └── execution-capsule.schema.json
└── scripts/
    └── validate_repo.py

Roadmap

Phase 0 — Specification

Define architecture and stage boundaries
Separate claims from hypotheses
Add machine-readable schemas
Add Codex repository instructions and skills
Add evaluation and ablation plan

Phase 1 — Reference orchestrator

Implement provider-neutral branch interface
Add native Codex CLI and deterministic mock adapters
Add deterministic run manifests and recorded seeds
Add isolated context workspaces
Add JSON Schema validation and repair policy
Add provenance store and blind payload builder
Add budget, quarantine, cancellation, and termination controls
Add structured event log
Add end-to-end tests and CI

Phase 2 — Codex Desktop workflow

Add artifact directories and branch manifests
Add worktree-aware orchestration helper
Add candidate normalization command
Add portfolio and Execution Capsule generation
Add restart-state view

Phase 3 — Benchmarks

Build budget-matched baselines
Run repeated trials
Add objective repository tasks
Add human expert review
Publish raw traces and analysis scripts

Phase 4 — Neuroinclusive evaluation

Co-design with developers with ADHD
Evaluate configurable display and action granularity
Measure interruption recovery and perceived control
Document harms, exclusions, and failed design assumptions

Contributing

Contributions are welcome when they improve the architecture, evidence, evaluation quality, accessibility, or implementation discipline.

Please read CONTRIBUTING.md. Significant implementation work should begin with an ExecPlan following PLANS.md.

Do not submit claims of superiority or novelty without:

a defined comparator;
a reproducible method;
raw results;
uncertainty;
a clear boundary on what the evidence supports.

Security and privacy

DDAC may process source code, architectural information, logs, and developer workflow state. Implementations must make data boundaries explicit and avoid treating hidden chain-of-thought as a required system artifact.

See SECURITY.md.

Citation

Citation metadata is available in CITATION.cff.

License

Licensed under the Apache License 2.0. See LICENSE.

Explore independently. Evaluate adversarially. Execute observably.

Name		Name	Last commit message	Last commit date
.agents/skills		.agents/skills
.github		.github
ddac		ddac
docs		docs
examples/payment-idempotency		examples/payment-idempotency
schemas		schemas
scripts		scripts
tests		tests
.gitignore		.gitignore
AGENTS.md		AGENTS.md
CITATION.cff		CITATION.cff
CODE_OF_CONDUCT.md		CODE_OF_CONDUCT.md
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
Makefile		Makefile
PLANS.md		PLANS.md
README.md		README.md
SECURITY.md		SECURITY.md
pyproject.toml		pyproject.toml

Latest commit

History

Folders and files

Repository files navigation

DDAC

Overview

Status

Quick start

Run with Codex

Why DDAC exists

Design goals

Architecture

System model

Stage 0 — Problem Stabilization

Gate

Stage 1 — Context-Isolated Divergence

Functional frames, not theatrical personas

Candidate contract

Stage 2 — Provenance-Blind Normalization

Stage 3 — Adversarial Convergence

Pass A — Eligibility

Pass B — Mechanism clustering

Pass C — Constraint-conditioned evaluation

Pass D — Mechanistic red team

Pass E — Portfolio selection

Stage 4 — Scaffolded Execution

Codex Desktop native

Native orchestrator

Recommended Codex Desktop workflow

1. Open the repository as a Codex project

2. Stabilize the problem in one thread

3. Launch independent divergence threads

4. Normalize and evaluate in a fresh thread

5. Create an ExecPlan for substantial work

6. Execute one capsule at a time

Why Codex Desktop is a natural fit

Adaptive control

ADHD-sensitive design

Scientific positioning

Selected research context

Formal hypotheses

Evaluation

Architecture study

Human workflow study

Required ablations

Repository map

Roadmap

Phase 0 — Specification

Phase 1 — Reference orchestrator

Phase 2 — Codex Desktop workflow

Phase 3 — Benchmarks

Phase 4 — Neuroinclusive evaluation

Contributing

Security and privacy

Citation

License

About

Topics

Resources

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages