English · Español
A governed framework for doing serious software engineering with AI without surrendering architectural control, evidence, or accountability.
The Engineering Intelligence System (EIS) Methodology is an open engineering framework developed by Ivan Longinus for structuring AI-assisted software development around explicit context, bounded work contracts, deterministic verification, durable memory, and human authority.
Its purpose is not to make an AI agent look autonomous. Its purpose is to make AI-assisted engineering more reliable, inspectable, reproducible, and scalable.
AI can accelerate engineering work. It should not weaken engineering discipline.
Draft 0.1 — open methodology.
EIS is a practical engineering framework, not a scientifically validated theory and not a certification standard. It is intended to be used, criticized, adapted, and tested across real software projects.
English is the canonical language. A Spanish translation is available in README.es.md.
AI coding tools can produce useful work very quickly, but speed creates a second-order problem: the engineer can lose control of context, architecture, scope, evidence, and continuity.
Common failure modes include:
- modifying code before understanding the real system state;
- solving the local symptom while breaking a global invariant;
- accepting plausible explanations instead of executable evidence;
- allowing scope to expand during implementation;
- treating prompts as architecture or policy;
- losing important decisions between sessions;
- duplicating or conflicting with concurrent work;
- declaring work complete because tests were mentioned rather than run;
- depending on one model's conversational memory;
- letting AI confidence substitute for engineering judgment.
EIS treats these as system-design problems around AI-assisted engineering, not as prompt-writing problems.
A model is not an engineering process.
Reliable AI-assisted engineering emerges when model capability is embedded inside a governed operating system for work:
Engineering Intelligence System =
Human judgment
+ Repository truth
+ Explicit context
+ Task contracts
+ Bounded AI execution
+ Tool discipline
+ Verification gates
+ Evidence
+ Durable memory
+ Reconciliation
The model may change. The durable asset is the engineering system around it.
EIS is concerned with how engineering work is performed with AI.
It governs:
- how the current state of a system is established;
- how a task is framed before mutation;
- how scope, invariants, risks, and non-goals are made explicit;
- how AI agents inspect and change a codebase;
- how tools, tests, migrations, browsers, databases, and CI are used as evidence sources;
- how completion claims are verified;
- how important findings and decisions survive beyond one chat session;
- how concurrent work is reconciled;
- where human authority remains mandatory.
It does not define how an AI feature inside a product should be architected. That is a separate problem.
The recommended EIS loop is:
Observe
→ Frame
→ Contract
→ Investigate
→ Design
→ Execute
→ Verify
→ Challenge
→ Record
→ Publish / Handoff
Establish the real state before reasoning from assumptions:
- repository and branch state;
- relevant architecture;
- current tests and gates;
- runtime or browser behavior when applicable;
- database and migration state when applicable;
- recent changes that may affect the task.
State the actual engineering problem, not merely the requested edit.
Define scope, invariants, non-goals, evidence requirements, risk boundaries, and completion criteria.
Trace the behavior through the real code and system boundaries before choosing a fix.
Prefer the smallest change that closes the identified failure mode without creating unnecessary architectural surface.
Perform bounded mutations with explicit tool use and clear ownership of side effects.
Run the checks that can disprove the implementation: tests, static analysis, database checks, runtime inspection, browser measurements, CI, or other domain-specific gates.
Try to break the claim. Use adversarial cases, mutation tests, negative controls, race conditions, stale state, permission failures, or alternate paths when the risk justifies them.
Persist decisions, findings, evidence, unresolved debt, and operational facts that matter beyond the current session.
Reconcile the final state, make the change reviewable, and leave the next engineer or agent with a truthful continuation point.
-
Repository truth over conversational memory
The codebase, database, runtime, and version-control state outrank what an agent remembers. -
Context before mutation
An AI system should inspect before it edits. -
Contract before implementation
Scope and completion conditions should be explicit before code changes begin. -
Invariants over symptoms
Fix the contract that failed, not only the visible manifestation. -
Minimal sufficient change
Broad refactors require evidence that the broader surface is necessary. -
Deterministic gates over verbal confidence
"Looks correct" is not a verification strategy. -
Evidence before completion
A completion claim should point to observable proof. -
Fail closed under material uncertainty
When required context, authority, or evidence is missing, stop the risky action rather than guess. -
Durable memory over session continuity
Important engineering state must survive model, session, and operator changes. -
Reconciliation before publication
Concurrent work, remote state, migrations, deployments, and generated artifacts must be reconciled before declaring a final state. -
Human authority at irreversible boundaries
Security-sensitive, destructive, production, financial, legal, or otherwise material actions remain subject to explicit human authority. -
Model portability
The methodology should remain useful when the model or AI vendor changes.
See PRINCIPLES.md.
EIS uses a small set of durable engineering artifacts:
- Task Contract — problem, scope, invariants, non-goals, risks, and completion criteria.
- Context Record — relevant system state established before mutation.
- Decision Record — an important engineering decision and its rationale.
- Evidence Record — executable proof supporting a claim.
- Finding Record — defect, debt, risk, or unresolved observation.
- Handoff Record — truthful continuation state for another session, engineer, or agent.
- Gate Registry — the checks that defend important contracts.
Templates are provided under templates/.
Under EIS, these statements are intentionally different:
Implemented
Tested
Verified
Certified
Published
A change can be implemented but not verified. It can be verified locally but not reconciled with the current remote or production state. It can pass tests while still lacking evidence for a specific invariant.
The framework therefore treats completion as an evidence-backed state transition, not a conversational declaration.
EIS does not replace software architecture, code review, CI/CD, testing, SRE, DevOps, threat modeling, ADRs, project management, or product discovery.
It composes those disciplines into a control system specifically for AI-assisted engineering.
Existing engineering disciplines
+
AI execution capability
+
Explicit governance and evidence
=
Engineering Intelligence System
See PRIOR-ART.md and NON-CLAIMS.md.
The methodology has been developed and refined by Ivan Longinus through real software engineering work, including the development of WorkB2B.
WorkB2B is cited as an application context, not as a dependency of the framework. EIS is intentionally generic and is designed to be usable across different codebases, stacks, organizations, AI models, and development workflows.
No private implementation details from applied projects are required to use the methodology.
.
├── README.md
├── README.es.md
├── SPEC.md
├── PRINCIPLES.md
├── METHODOLOGY.md
├── MATURITY_MODEL.md
├── NON-CLAIMS.md
├── LIMITATIONS.md
├── PRIOR-ART.md
├── CONTRIBUTING.md
├── SECURITY.md
├── CITATION.cff
├── LICENSE.md
├── CHANGELOG.md
├── docs/
├── templates/
├── schemas/
└── examples/
Do not begin by automating the entire engineering organization.
Start with one class of work and make its control loop explicit:
- define the task contract;
- establish required context;
- identify the gates that can falsify the change;
- require evidence for completion;
- persist decisions and findings;
- measure where AI saved time and where it created rework;
- expand only when the process remains understandable and reviewable.
See METHODOLOGY.md and MATURITY_MODEL.md.
If you use or discuss this methodology, see CITATION.cff.
The conceptual and written material in this repository is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). See LICENSE.md.