Inspiration
Most AI coding systems are optimized to generate an answer, propose a patch, or produce code quickly.
PROMETHEUS began with a harder engineering question:
How do we know the software was actually built correctly?
A generated answer is not the same as a verified result.
Code can compile while the intended behavior remains broken. Tests can be incomplete. Repair scripts can exist without ever being executed. Artifacts can change after validation. An AI can report success confidently without preserving enough evidence to prove what actually happened.
PROMETHEUS was built to close that gap.
It is a self-proving, self-repairing AI engineering organism that converts a software mission into an observable, evidence-governed execution campaign.
The system does not treat “the code was generated” as completion.
It treats completion as a claim that must survive execution, adversarial challenge, repair, regression testing, artifact verification, and proof review.
What it does
PROMETHEUS accepts an engineering mission and moves it through a complete Command-to-Proof lifecycle.
In the competition demo, PROMETHEUS performs the following sequence:
Mission intake The engineering objective is validated, structured, and translated into explicit acceptance criteria.
Atomic task decomposition The mission is divided into proof-bearing work packets with defined inputs, outputs, tests, dependencies, and completion conditions.
Candidate generation and routing PROMETHEUS can evaluate multiple implementation or repair routes instead of committing blindly to the first generated answer.
Real execution Commands are executed against real files, real code, and a real test environment.
Failure detection The system surfaces an actual failing condition rather than masking it behind a successful process launch or optimistic status message.
Failure-closed promotion SECA blocks the task from being declared complete while required evidence is missing or tests remain unsuccessful.
HYDRA repair HYDRA diagnoses the failure, selects a repair route, applies a controlled correction, and records the repair attempt.
Test and regression rerun The affected test is rerun along with the required regression checks.
ProofGrid verification PROMETHEUS verifies receipts, commands, artifacts, hashes, lineage, acceptance criteria, and promotion status.
Capability Genome creation The verified repair is preserved as a reusable capability record.
Capability reuse PROMETHEUS can match that Genome against a related future task and apply the proven repair pattern through the same verification process.
The central principle is:
«PROMETHEUS does not merely generate software. It proves what happened, repairs what failed, and preserves what worked.»
The competition demo
The demo is designed to show the system operating, not merely describe the architecture.
PROMETHEUS begins with an engineering mission and exposes the campaign state through its operational interface.
The viewer sees:
- the mission entering the system
- the work being decomposed
- a real execution path beginning
- an actual failure being detected
- promotion being blocked
- HYDRA selecting and applying a repair
- tests being rerun
- verification succeeding
- proof receipts being generated
- the result being promoted
- a Capability Genome being created
- the verified capability being reused
This sequence demonstrates the difference between ordinary AI code generation and evidence-governed autonomous engineering.
The demo is not built around a simulated success screen.
Its core event is a controlled failure that PROMETHEUS must detect, repair, retest, verify, and convert into reusable engineering knowledge.
HYDRA
HYDRA is the adaptive repair engine inside PROMETHEUS.
When a task fails, HYDRA does not simply repeat the same command and hope for a different result.
It records the failure signature and uses that evidence to guide the next action.
A HYDRA repair cycle can include:
- capturing the failed command
- recording the exit state
- identifying the affected component
- classifying the failure signature
- selecting an appropriate repair strategy
- applying the repair in a controlled path
- rerunning the affected tests
- running regression checks
- rejecting ineffective strategies
- changing routes after repeated failure
- preserving the successful repair lineage
The repair is not considered successful merely because a file changed.
Promotion remains blocked until the repaired result passes the required verification gates.
The visible lifecycle is:
MISSION RECEIVED → COMMAND EXECUTED → REAL FAILURE DETECTED → PROMOTION BLOCKED → FAILURE SIGNATURE CAPTURED → HYDRA REPAIR SELECTED → REPAIR APPLIED → AFFECTED TESTS RERUN → REGRESSION TESTS PASSED → PROOF VERIFIED → RESULT PROMOTED
HYDRA turns failure from a dead end into structured engineering evidence.
SECA
SECA is the completion authority and claim-control layer.
Its purpose is to prevent PROMETHEUS from confusing activity with completion.
A process being alive does not mean the mission is progressing.
A patch being written does not mean the defect is repaired.
A receipt being generated does not mean the receipt is trustworthy.
A test passing once does not mean the surrounding system remains intact.
SECA evaluates whether the evidence required for promotion actually exists.
It can block completion when:
- required tests have not passed
- acceptance criteria are incomplete
- artifacts are missing
- proof receipts are invalid
- hashes do not match
- execution lineage is incomplete
- a repair has not been regression-tested
- the claimed result exceeds the available evidence
This makes PROMETHEUS failure-closed rather than confidence-open.
Unsupported success claims do not pass.
ProofGrid
ProofGrid is the verification and evidence layer of PROMETHEUS.
It connects engineering claims to physical proof.
ProofGrid can preserve and validate:
- executed commands
- timestamps
- task identifiers
- mission identifiers
- input and output artifacts
- test results
- exit codes
- repair attempts
- acceptance criteria
- artifact hashes
- file lineage
- checkpoint state
- promotion decisions
- provenance records
- Capability Genome creation events
The system uses cryptographic hashes, including SHA-256, to help verify that the artifacts being reviewed are the artifacts that were actually produced.
A result is not promoted because PROMETHEUS says it is complete.
It is promoted because the required evidence supports that conclusion.
Capability Genome
A verified repair should not disappear after one successful mission.
PROMETHEUS converts successful repairs into reusable Capability Genomes.
A Capability Genome can contain:
- trigger conditions
- failure signatures
- applicability rules
- repair strategy
- affected components
- command sequence
- required tests
- regression requirements
- verification rules
- provenance
- artifact hashes
- confidence state
- reuse history
- promotion history
The Genome acts as a reusable, evidence-backed engineering capability.
When PROMETHEUS encounters a related task, it can compare the new failure or mission conditions against previously verified Genomes.
A matching Genome is not applied as an unverified shortcut.
It is routed back through the same Command-to-Proof process:
RELATED TASK → GENOME MATCH → APPLICABILITY CHECK → CONTROLLED REUSE → TEST EXECUTION → PROOF VERIFICATION → PROMOTION OR REJECTION
This allows PROMETHEUS to repair, prove, remember, reuse, and evolve.
Build Truth
PROMETHEUS maintains an operational Build Truth representing the evidence-supported state of the campaign.
Build Truth separates:
- what was requested
- what was attempted
- what actually executed
- what failed
- what was repaired
- what passed
- what remains blocked
- what evidence exists
- what can safely be claimed
This prevents the system from treating plans, generated files, running processes, and verified results as though they were equivalent.
Build Truth is the current engineering reality of the mission.
Every promotion decision must be supported by it.
Checkpointing and recovery
Autonomous engineering campaigns can be interrupted by process crashes, terminal failures, machine restarts, incomplete writes, or external service problems.
PROMETHEUS uses durable checkpoints so campaign progress can be resumed without pretending unfinished work was completed.
Checkpoint records can preserve:
- mission state
- task state
- execution stage
- completed proof packets
- pending proof packets
- failed commands
- repair attempts
- artifact locations
- test status
- promotion status
- recovery instructions
This gives the system a recoverable operational memory rather than relying on the temporary context of a single model response.
ServerForge and observability
ServerForge provides an external observability route for PROMETHEUS campaigns.
It can publish structured campaign events into Discord so mission activity can be observed outside the local terminal.
These events can include:
- mission initialization
- task transitions
- failures
- repair attempts
- blocked promotions
- test outcomes
- verification results
- proof receipts
- capability creation
- final campaign status
This makes the engineering process easier to inspect, communicate, and audit.
The Discord layer is not the source of truth.
It is an observability surface connected to the evidence-governed runtime.
EDEN integration
PROMETHEUS was developed and operated through the broader EDEN local runtime environment.
EDEN provides the local execution body surrounding the project, including development orchestration, runtime launch, process supervision, local file access, PowerShell integration, and system coordination.
PROMETHEUS functions as the evidence-governed engineering organism inside that environment.
The current competition build focuses on the demonstrable Command-to-Proof loop while preserving a path toward deeper EDEN integration, remote control, distributed execution, and mobile observability.
How we built it
PROMETHEUS was developed as a modular Python-based engineering runtime with a command-line interface and an evidence-first execution architecture.
The project includes systems for:
- mission validation
- task decomposition
- deterministic execution
- candidate routing
- command orchestration
- test execution
- failure classification
- adversarial review
- repair selection
- repair application
- regression testing
- proof receipt creation
- artifact hashing
- checkpoint recovery
- promotion control
- capability preservation
- capability reuse
- external observability
Codex
Codex was used as an active engineering partner throughout repository inspection, implementation, debugging, test creation, refactoring, packaging, and competition closure.
It supported the work of turning architectural intent into executable repository changes.
GPT models
GPT models were used for:
- mission reasoning
- candidate generation
- task decomposition
- failure analysis
- repair strategy generation
- adversarial evaluation
- acceptance-criteria refinement
- judge-facing technical documentation
Python
Python provides the primary runtime, mission engine, task logic, receipt generation, proof handling, repair workflows, and Capability Genome structures.
Pytest
Pytest is used to execute functional tests, repair validation, and regression checks.
PowerShell
PowerShell provides local orchestration across the Windows environment, including runtime launch, command execution, evidence capture, process supervision, recovery, and integration with the broader local development system.
Git and GitHub
Git and GitHub preserve:
- implementation lineage
- commit history
- repository state
- release state
- recovery points
- public source access
- competition delivery
Discord
Discord serves as an external observability surface through ServerForge, allowing campaign events and case-study evidence to be published beyond the local runtime.
Challenges
The greatest challenge was not generating additional architecture.
It was forcing every important claim to converge into physical proof.
PROMETHEUS had to distinguish between:
- a process being alive and a campaign actually progressing
- code being generated and code being executed
- a repair script existing and a repair being proven
- a test running and the correct test running
- a receipt being generated and a receipt being trustworthy
- an artifact existing and an artifact retaining verified integrity
- a task succeeding once and a capability being genuinely reusable
- impressive system language and reproducible engineering evidence
Building the system required repeated work on:
- deterministic execution
- failure-state visibility
- checkpoint recovery
- telemetry
- receipt validation
- artifact hashing
- test isolation
- regression coverage
- repair routing
- Git lineage
- honest status reporting
- promotion rules
- demo reliability
A major design challenge was preserving the ambition of an autonomous engineering organism while making the competition build understandable in a short demonstration.
The final demo solves this by presenting one complete narrative:
MISSION → FAILURE → BLOCK → REPAIR → RETEST → VERIFY → PROMOTE → REMEMBER → REUSE
What we learned
We learned that autonomous engineering requires far more than reasoning and code generation.
It requires:
- explicit acceptance criteria
- observable execution
- durable checkpoints
- adversarial verification
- failure-closed promotion
- reproducible tests
- regression protection
- trustworthy receipts
- artifact integrity
- honest blockers
- repair lineage
- reusable verified knowledge
We also learned that a system should not be rewarded for sounding certain.
It should be rewarded for producing inspectable evidence.
The most important lesson was:
«Trustworthy autonomy is not created by increasing the confidence of the model. It is created by increasing the quality of the proof.»
Accomplishments
PROMETHEUS successfully demonstrates a complete evidence-governed engineering cycle:
- mission intake
- atomic task creation
- real command execution
- real failure detection
- blocked promotion
- HYDRA repair
- test rerun
- regression verification
- proof receipt creation
- artifact hashing
- verified promotion
- Capability Genome generation
- capability reuse
- GitHub publication
- external observability
The project moves beyond a conventional AI coding assistant by treating proof, recovery, repair, and reusable engineering memory as first-class system components.
What is next
PROMETHEUS is being extended toward larger and longer-running engineering campaigns.
Planned directions include:
- multi-repository missions
- richer Capability Genome matching
- distributed execution
- parallel candidate evaluation
- stronger adversarial agents
- deeper CI integration
- improved visual observability
- remote campaign control
- mobile control through EDEN
- expanded ServerForge integrations
- stronger provenance graphs
- signed evidence bundles
- larger regression matrices
- human approval gates for sensitive operations
- deeper development-tool integrations
The long-term goal is an engineering organism that can continuously:
BUILD → EXECUTE → TEST → CHALLENGE → REPAIR → VERIFY → PROVE → REMEMBER → IMPROVE
while preserving a complete lineage of how every result was produced.
Built with
Enter these as separate Devpost tags:
Python OpenAI Codex GPT PowerShell Git GitHub Pytest JSON JSONL SHA-256 CLI AI Agents Agentic AI Software Engineering DevTools Automation Test Automation Self-Healing Systems Adversarial Testing Continuous Integration Observability Cryptographic Verification Windows Discord
Try it out
Interactive competition demo
Source code
https://github.com/Atlas-Ascend/-PROMETHEUS-AIS-Competition
PROMETHEUS evolved from NHCM-I: Neo-Hermetic Cybernetic Mindstate, a published framework for recursive intelligence, symbolic cognition, feedback-driven self-revision, and self-organizing systems. PROMETHEUS translates those principles from a cognitive and philosophical model into an operational engineering organism that can execute, test, repair, verify, and preserve proof of its work.
Built With
- codex
- discord
- ollama
- python
Log in or sign up for Devpost to join the conversation.