-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the e2eengine wiki!# E2E Engine
Build with AI. Verify with engineering discipline.
E2E Engine is a runtime-neutral engineering control plane for AI-assisted software development.
It coordinates AI engineering workers, understands the repository, applies engineering rules and security guardrails, evaluates changes, performs independent verification, and produces evidence for engineering decisions.
The core idea is simple:
AI can generate software. E2E Engine helps determine whether that software should be trusted.
AI coding agents can already write code, modify repositories, run commands, and fix failures.
The difficult problem is no longer simply:
"Can AI write the code?"
The harder questions are:
- Did the AI understand the existing architecture?
- Did it modify the correct parts of the repository?
- Did it introduce regressions?
- Did it weaken a test to make the test pass?
- Did it introduce unnecessary dependencies?
- Did it satisfy the actual requirement?
- Did it create security or integration problems?
- Is the implementation really complete?
- Can we provide evidence that the change works?
E2E Engine is designed around these questions.
E2E Engine provides an engineering layer around AI coding runtimes.
ENGINEERING REQUEST
│
▼
Context + Rules
│
▼
CodeBrain
│
▼
Engineering Intelligence
│
▼
SD3 Supervisor
│
▼
SD2 Orchestrator
│
┌───────────┼───────────┐
▼ ▼ ▼
SD1 SD1 SD1
Worker Worker Worker
│ │ │
└───────────┼───────────┘
▼
Testing + Evaluation
│
▼
SD3 Verification
│
┌─────────┴─────────┐
▼ ▼
Correct Accept
│ │
▼ ▼
Verify Again Evidence
E2E Engine separates doing, coordinating, and verifying.
SD1 workers perform bounded engineering tasks.
Examples:
- Frontend implementation
- Backend implementation
- API development
- Database changes
- Testing
- Security analysis
- DevOps
- UI/UX
- Documentation
- SEO
- Web intelligence
A worker is responsible for performing its assigned task and producing evidence.
A worker does not have final authority over whether its own work should be accepted.
SD2 coordinates engineering work.
It can:
- Decompose requirements
- Select specialist workers
- Determine dependencies
- Identify safe parallel work
- Sequence tasks
- Aggregate worker results
- Coordinate corrections
- Prepare work for verification
SD2 answers:
"What work needs to happen, who should perform it, and in what order?"
SD3 is the independent engineering verification layer.
It evaluates:
- Requirements
- Architecture
- Implementation
- Security
- Integration
- Tests
- Regression risk
- Evidence
- Repository state
SD3 can:
APPROVE
CORRECT
REJECT
ESCALATE
The important principle is:
The agent that performs the work should not be the only authority deciding that the work is correct.
E2E Engine includes CodeBrain, a repository intelligence layer.
Instead of treating every request as an isolated prompt, E2E can build a model of the repository.
CodeBrain can analyze:
- Files
- Symbols
- Imports
- Dependencies
- Call relationships
- Callers and callees
- Impact areas
- Existing implementations
- Relevant repository context
This allows engineering workers to receive repository-grounded information before implementation.
User Request
│
▼
CodeBrain
│
├── Relevant files
├── Relevant symbols
├── Dependencies
├── Callers / callees
├── Existing patterns
└── Impact analysis
│
▼
Engineering Plan
E2E Engine combines repository information with engineering history and rules.
Task
│
┌──────────┼──────────┐
▼ ▼ ▼
CodeBrain Rules Skills
│ │ │
└──────────┼──────────┘
▼
Memory
│
▼
Evaluation History
│
▼
Regression Analysis
│
▼
Engineering Intelligence
This allows the system to identify areas that require stronger verification.
For example:
LOW RISK
│
└── Standard implementation
+ targeted tests
MEDIUM RISK
│
└── Integration verification
+ regression checks
HIGH RISK
│
└── Security review
+ stronger testing
+ independent SD3 verification
A central principle of E2E Engine is:
A successful agent response is not proof of successful engineering.
Instead of accepting:
Agent:
"Authentication has been implemented successfully."
E2E aims to establish:
Requirement
↓
Implementation
↓
Tests
↓
Evaluation
↓
Security checks
↓
Regression checks
↓
Independent verification
↓
Evidence
The result should be supported by evidence rather than an agent's statement.
E2E Engine uses a progressive proof model.
P0 Internal Health
│
▼
P1 Deterministic Evaluation
│
▼
P2 Orchestration Proof
│
▼
P3 Real Worker Execution
│
▼
P4 Independent SD3 Verification
│
▼
P5 Failure + Recovery
│
▼
P6 Repeated Benchmark
│
▼
PROVEN
A green CI workflow is useful evidence, but it does not automatically mean that the complete engineering system has been proven.
Higher proof levels require stronger and more realistic evidence.
One important goal is preventing situations where an AI system makes a test pass without actually solving the underlying problem.
For example:
Implementation fails
│
▼
Agent modifies test
│
▼
Test passes
│
▼
"Success"
E2E should instead examine whether:
- Assertions were weakened
- Tests were removed
- Tests were skipped
- Coverage was reduced
- Failure conditions were deleted
- Validation configuration was weakened
- Existing regression protection was bypassed
The goal is:
A passing test should provide meaningful evidence, not merely a green exit code.
E2E Engine uses deterministic engineering guardrails rather than relying entirely on AI instructions.
Guardrails can cover areas such as:
- Protected paths
- Secret detection
- Tool permissions
- Lifecycle checks
- Evidence requirements
- Risk boundaries
- Runtime actions
- Verification requirements
The principle is:
AI instruction
≠
Security boundary
Security-critical controls should be enforced by deterministic mechanisms whenever possible.
E2E Engine treats tools as controlled engineering capabilities.
A tool can be governed by:
- Role
- Scope
- Risk
- Approval requirements
- Execution context
- Evidence requirements
Conceptually:
Worker
│
▼
E2E Tool Policy
│
├── Is this tool allowed?
├── Is this scope allowed?
├── What is the risk?
├── Is approval required?
└── What evidence is required?
│
▼
Tool
MCP can provide interoperability, but E2E Engine does not treat MCP itself as the engineering authorization boundary.
E2E Engine is designed to work above individual AI coding runtimes.
E2E Engine
│
┌─────────┼─────────┐
▼ ▼ ▼
Claude Codex Future
Code Runtime
│ │ │
└─────────┼─────────┘
▼
Engineering Contract
This means the engineering system does not need to be permanently tied to one model provider.
The AI runtime can change while the engineering policies, skills, verification model, and evidence system remain consistent.
E2E Engine can provide web intelligence as a capability rather than making a specific crawler the core architecture.
Potential uses include:
Analyze public websites to understand:
- Page structure
- Navigation
- Content organization
- Forms
- Features
- Pricing structures
- Public documentation
Use public websites as research inputs for:
- UX patterns
- Navigation patterns
- CTA structures
- Information architecture
- Feature organization
Analyze public website structures to help derive:
Website
↓
Page structure
↓
Data patterns
↓
Schema
↓
Synthetic test fixtures
Analyze public information such as:
- Titles
- Headings
- Metadata
- Links
- Images
- Structured data
- Content organization
- Public competitor information
E2E keeps the capability vendor-neutral so implementations can change over time.
E2E separates execution from evaluation.
Evaluation can include:
- Deterministic command graders
- Exit-code checks
- Content checks
- File-existence checks
- Repeated attempts
- Pass-rate measurements
pass@kpass^k- Latency measurements
- Baseline comparisons
- Regression detection
- Persisted evidence
This allows the system to measure engineering behavior instead of relying solely on subjective agent responses.
Previous failures should become useful signals.
Previous Run
│
▼
Failure
│
▼
Evaluation History
│
▼
Regression Intelligence
│
▼
Future Planning
│
▼
Stronger Verification
Memory and historical evaluation are advisory.
They should improve planning and verification but should never become an authorization boundary.
E2E Engine is designed to retain engineering evidence.
Evidence can include:
- Plans
- Worker reports
- Test results
- Evaluation results
- Verification results
- Introspection
- Regression information
- Final outcomes
- Run metadata
This makes an engineering run more inspectable and reproducible.
The goal is to move from:
"The AI says it worked."
to:
"Here is the evidence showing what was changed, what was tested, what was verified, and why it was accepted."
E2E Engine also supports controlled CI self-healing.
The conceptual workflow is:
CI Failure
│
▼
Collect Evidence
│
▼
Diagnose
│
▼
Propose Repair
│
▼
Apply Repair
│
▼
Run Local Verification
│
▼
Commit Validated Change
│
▼
Run CI Again
│
▼
Independent Verification
The repair process must not:
- Delete tests
- Weaken tests
- Disable verification
- Bypass engineering guardrails
- Accept unverified changes
Self-healing is intended to repair engineering defects, not hide them.
E2E Engine follows a minimality ladder:
Need
↓
Reuse
↓
Standard Library
↓
Native Tooling
↓
Existing Dependency
↓
Simple Implementation
↓
Custom Abstraction
The goal is to avoid unnecessary complexity.
AI systems can easily introduce additional frameworks, dependencies, abstractions, and services.
E2E encourages:
Use the smallest reliable mechanism that solves the problem.
E2E Engine is not intended to replace Claude Code, Codex, or other AI coding systems.
Instead:
AI Coding Agent
↓
Worker
↓
E2E Engineering Layer
↓
┌───────────────┐
│ Context │
│ Orchestration │
│ Guardrails │
│ Evaluation │
│ Verification │
│ Evidence │
└───────────────┘
The distinction is:
AI agents perform engineering work. E2E Engine controls and verifies the engineering process around that work.
E2E Engine is built around several principles.
A worker should show what happened rather than simply claiming success.
Execution and verification should be separate responsibilities.
Critical boundaries should not depend only on model behavior.
Prefer the smallest correct implementation.
Understand the existing system before modifying it.
Historical information should influence planning, not authorization.
Evaluation failures should strengthen future engineering decisions.
Persistent failures should escalate instead of looping indefinitely.
Engineering standards should remain portable across AI runtimes.
A successful command is not automatically proof of engineering correctness.
Suppose a developer requests:
"Add authentication to my application."
E2E Engine can approach the task as:
1. Understand the repository
↓
2. Identify authentication-related components
↓
3. Analyze architecture and dependencies
↓
4. Identify security and regression risks
↓
5. Build an engineering plan
↓
6. Assign specialist workers
↓
7. Execute bounded changes
↓
8. Run tests
↓
9. Evaluate the implementation
↓
10. Check regression risk
↓
11. Perform independent SD3 verification
↓
12. Correct problems if required
↓
13. Verify again
↓
14. Produce evidence
The important difference is that the process does not end when the AI says:
"Done."
It ends when the required engineering evidence is sufficient.
E2E Engine is intended for:
Use AI coding agents while maintaining stronger control over repository changes.
Coordinate AI-assisted development without relying entirely on manual inspection.
Create consistent engineering policies across AI-assisted workflows.
Use E2E as a control and verification layer around multiple AI runtimes.
Experiment with:
- Agent orchestration
- Engineering verification
- AI coding reliability
- Regression intelligence
- Proof systems
- Multi-agent software development
E2E Engine is based on one central idea:
AI can make implementation dramatically faster.
That makes verification, governance, context, testing, and evidence increasingly important.
E2E Engine aims to provide that missing engineering layer.
The long-term direction includes:
- Stronger repository intelligence
- More specialist engineering skills
- Improved SD2 planning
- Stronger SD3 verification
- More deterministic verification
- Better regression intelligence
- Expanded runtime adapters
- More evaluation benchmarks
- Stronger security boundaries
- More proof levels
- Production-scale engineering evidence
- Additional web and external intelligence capabilities
E2E Engine is an actively developed open-source project.
The current foundation includes:
- Repository intelligence
- Context and rules
- Specialist skills
- SD1 / SD2 / SD3 architecture
- Multi-worker orchestration
- Deterministic guardrails
- Evaluation history
- Regression intelligence
- Runtime adapters
- MCP integration
- Execution artifacts
- Introspection
- Evaluation harness
- CI self-healing
- Web Intelligence capability
- Proof workflows
Important: A green CI workflow should not automatically be interpreted as proof of production-grade AI engineering reliability. Stronger claims require the corresponding proof levels and evidence.
Contributions are welcome.
Before contributing:
- Understand the architecture.
- Read the repository's agent and engineering instructions.
- Follow the relevant authoring standards.
- Keep changes minimal.
- Add tests for behavioral changes.
- Run relevant guardrails and evaluations.
- Never weaken or delete tests simply to make a workflow pass.
- Provide verification evidence for substantive changes.
E2E Engine is released under the MIT License.
AI GENERATES
│
▼
E2E CONTROLS
│
▼
E2E EVALUATES
│
▼
E2E VERIFIES
│
▼
E2E PRODUCES PROOF
│
▼
ENGINEERING TRUST
Build with AI. Verify with engineering discipline.