Engineering Intelligence Framework
A governed methodology that lets engineering experience compound.
EIF turns validated engineering experience into reusable operational intelligence: one shared operating layer, project memory, session discipline and invokable skills that outlive any single session.
AI coding agents are powerful, but most workflows still treat a session as if it were durable engineering knowledge.
At closeout, a session records a Knowledge Delta. This EIF artifact captures the change in knowledge. It is checked, kept in the project, or explicitly promoted into a reusable rule, playbook, template, or skill.
In EIF, Engineering Intelligence means versioned engineering experience plus the methods that govern its use. It shapes how the next task is prepared, executed, and verified. It is more than a place to store knowledge.
“Learning” happens at the system level. Validated experience becomes a reviewed, versioned artifact that the next session can retrieve. EIF does not train model weights, fine-tune an LLM, or let an agent rewrite its own safeguards.
EIF separates reusable framework methodology, durable project knowledge and ephemeral session context into three layers, with Knowledge Delta governing promotion between them.
The reusable operating layer for agent work: ontology, the authority model, global rules, playbooks, templates and invokable skills. More than method, and shared across every project.
How to work
Architecture, decisions, domain facts, incidents, risks and local conventions that belong to one project.
An optional private workspace can coordinate several projects inside L2. It selects and pins shared rules, skills, playbooks and templates into each project without becoming another layer or owning project content.
What this system knows
Current scope, progress, observations, assumptions, open questions and a draft Knowledge Delta.
What is happening now
Flows down: the whole operating layer together with the project's own prior experience. Ontology, the authority model, rules, playbooks, templates and skills all reach the session before implementation starts.
Flows up: only validated knowledge, and only by a separate decision recorded in Knowledge Delta. It usually stays on the layer where it was found. Promotion is the exception, not the required closing step of every session.
One packet, two sessions, three questions: what each session is given before it writes anything, what survives its closeout, and what session 2 finds already waiting for it.
Retrieval, not recall. A session opens by searching durable knowledge for prior lessons, rejected approaches and repeat failures. Work under EIF begins with this step, even when a task looks simple.
Packet memory. A task spanning several sessions gets a packet: charter, facts, decisions and roadmap written before implementation. That is what carries across the gap, so session 2 does not reopen what session 1 settled.
Retro, then Knowledge Delta. Closeout compares intent against evidence and names the failure patterns. Raw reasoning is dropped on purpose; only structured, sourced results become project memory.
Promotion is the exception. A lesson leaves its project only if it applies beyond it, passes a lint on source and type, and an owner accepts it. Most validated knowledge is meant to stay local.
One shared operating layer at the centre, and every project on its own orbit around it. The centre holds what is reusable everywhere: ontology and the authority model, rules and constraints, playbooks, templates and skills. Each project keeps its own repository and its own memory, and retrieves from the centre before it starts. Under P1 a packet of three sessions is open, because the task was too large for one of them. Method and the project's own history descend into those sessions before their first line of implementation; when the packet closes, a validated lesson can climb back to the centre, and from there reach another project only where it applies.
EIF is a control plane that coordinates tools and agents without replacing them. It connects knowledge, authority, execution and evidence into a single, observable sequence.
A task or question enters the loop.
Prior validated knowledge is pulled into context before new work starts.
What should happen, what actually happens, and what may be cited are kept as separate questions.
An optional code graph may help find things faster. It is navigation evidence, not authority.
Work proceeds under explicit scope, budgets and stop conditions.
A merged change is not treated as proof of working behavior on its own.
What was learned is written down in the same session, not left in chat.
Validated knowledge is available to the next task and the next agent.
Source files remain authority throughout. An optional structural graph, when present, is navigation evidence: it does not replace source verification.
EIF requires retrieval of relevant prior knowledge before non-trivial work and defines preparation, controlled execution, verification and closeout as the session lifecycle.
Read active instructions and source, then search durable knowledge for relevant lessons, failures and rejected approaches.
Choose a single session or an execution packet. Name the goal, evidence, constraints, budgets and stop conditions.
Keep observations separate from assumptions, work within scope and use declared evaluators instead of completion language.
Record actual evidence, open work and Knowledge Delta. Retain validated learning; remove or discard ephemeral session state.
The session layer is a checkpoint, not memory: it may contain progress, evidence labels, open questions and a draft delta, but no raw AI reasoning. It is never promoted wholesale.
EIF includes a bounded evidence-loop contract for iterative agent work, with explicit evaluators, budgets, evidence and stop conditions. This is a methodology contract. It does not by itself prove fewer retries, higher quality, lower cost, or reliable autonomous completion.
Read current source and relevant retrieved knowledge. Record facts separately from assumptions.
State the next smallest hypothesis and the observation that would confirm or reject it.
Make one reversible change or run one diagnostic experiment.
Run the declared evaluator and record its actual output.
Compare expected and actual results. If unsuccessful, record a concise failure signature comparable across attempts.
Select the next action because of the observation. An unchanged failing action with no new evidence is not repeated.
Declared before the first iteration. Without them an agent is not iterating, it is retrying.
Three ways out and no fourth. Each one names the evidence or the boundary that ended the loop.
Learning becomes durable only when a session's validated Knowledge Delta is classified, linted, retained locally or explicitly promoted into a versioned rule, playbook, template or skill.
Two loops, not one. The inner loop runs inside a session and asks what this session learned. The outer loop runs across many sessions and asks a question no single closeout can answer: what keeps happening? A lesson seen once is an incident. The same failure signature seen repeatedly is a missing rule.
Real work produces evidence: a fact, incident, rejected approach, risk or repeatable method.
The session records a concise Knowledge Delta, including what remains unverified.
The outer loop, across a packet or several weeks: derive the period from the repository, then find what repeats. Running it over one session finds nothing, by design.
Knowledge Ingest and Lint check artifact type, source, status, language, duplication and links.
Project-specific knowledge stays in the project layer; a general lesson reaches the framework layer only by explicit decision.
The next relevant session finds the artifact before acting, closing the learning loop.
Every artifact is a plain file with structured front matter:
type, scope, status, confidence, source, and
related: links to its neighbours. Those links are
what make it a graph instead of a pile - a decision points at
the incident that caused it, a lesson at the rule it became.
related: link.Facts, decisions, incidents, edge cases, failure patterns and lessons with provenance and lifecycle status.
A reusable, invokable workflow for planning, execution, review, retrieval or curation. It is versioned instructions, not hidden model behavior.
This is governed system-level learning, not autonomous self-modification. A lesson can be rejected, remain local, expire or be superseded; a local skill may specialize workflow but cannot lower framework safety rules.
Graphify, RTK and Context7 each add one narrow capability. None is the methodology itself, and the framework installs none of the three.
EIF takes the fallback path and reports the tool as unavailable instead of quietly substituting a guess: source search instead of the graph, unfiltered output instead of compression, local documentation instead of a live lookup.
Boundary: local for AST-based extraction. It reaches an external API only if semantic labeling is turned on deliberately.
Without it: the agent falls back to source search and manual browsing, with no graph-level path or impact hints.
Verified: D-08 metadata binds the graph digest to its source commit, the Graphify version, an explicit repository identity and the reviewed scope. Only fresh reports healthy; a code, semantic or history change asks for the matching update, and an invalid or deliberately suppressed artifact stays unavailable. Bounded to one local version and one small synthetic fixture, not a navigation outcome.
Boundary: local, with nothing sent anywhere.
Without it: shell commands run unfiltered and no reduction is recorded.
Verified: RTK 0.43.0 passes all 24 checks on the tested Windows host through the native rtk rg route. A failed required canary still reports degraded, and a raw or failed proxy route records zero savings rather than a positive number. Not a cross-platform or efficiency claim.
Boundary: the query text goes to the network to reach a hosted documentation service. The framework sends no source code.
Without it: the agent relies on local docs or training-data recall, which may describe a different version than the one installed. An unavailable provider is reported, never silently replaced by recall.
EIF does not install it. An MCP server is configured at the user level, outside the project instance, and the framework never changes user-level configuration. It ships generated routing guidance and a reviewable per-adapter template whose provider command stays owner-supplied.
Verified: the declaration, the routing guidance and the template shape are covered by tests; live provider behavior is not. EIF generates configuration for the agent to load and does not speak MCP itself, so reachability is reported by the agent and stays marked unverified.
Eight things this framework does now, each with the check behind it and the scope that check covers. The scope line belongs to the row it qualifies, not to a disclaimer at the foot of the page.
The wheel attached to GitHub Releases, or pip install . from a clone, gives you a working eifctl. Its eleven commands cover private-workspace and project creation, connection, guarded two-axis updates, verification, retrieval, rendering and validation. The installed wheel is exercised through the workspace lifecycle and a synthetic task, not by an import check.
Scope: the artifact is available on GitHub Releases, but it is not published to PyPI. Each creation command makes a local repository, not a GitHub remote. Multi-project updates are preflighted but not atomic across repositories.
The adoption preflight reads the repository before it writes anything. If the project is already governed it stops and asks for an explicit decision instead of taking over, and in coexist mode the generated block defers to the rules already there rather than declaring itself the only authority.
Scope: existing governance is recognised by the size and shape of the files, not by reading what they mean. Verified against a synthetic fixture and repeated runs against one real private repository.
Search runs offline over the project's own index, aware of each artifact's schema and its place in the lifecycle. Rejected and superseded artifacts stay readable but are kept out of results by default, and unparseable, schema-invalid and not-found come back as three different answers rather than one empty one. Ukrainian artifacts are indexed and returned like any other.
Scope: keyword and substring scoring, not search by meaning. No embedding service, and nothing leaves the machine.
A unit of work opens as a session or as an execution packet with the evaluator named up front, budgets for iterations and remote runs, and a stop condition that does not depend on the agent deciding it is finished (see the evidence loop).
Scope: a contract the workflow holds itself to. It sets how work is bounded, not how many attempts a given task will take.
The bundled verifier recomputes the manifest digests from the files on disk, validates config and lock against their schemas, and checks that the active adapter matches the configuration, that the generated entrypoint has not drifted from the config that produced it, and that the block markers are intact.
Scope: it verifies the EIF bundle it manages. It is not a general file-integrity tool for the rest of the repository.
Claude Code, Cursor, Codex and Hermes. All twelve ordered pairs are exercised: after every switch there is exactly one active EIF block, the new adapter's entrypoint resolves to the right source, and the project's own content is left as it was.
Scope: adapter coverage is these four, deliberately, and the core is plain Markdown any other agent can be pointed at. What differs between them is mechanics, not status: Cursor has no tool-call hook to enforce through, so its adapter ships rules, and the Codex and Hermes hook contracts block rather than rewrite.
Retrieval, Knowledge Delta rendering, session closeout and the generated entrypoint content all render in the language the instance declares, verified in Ukrainian as well as English. The language is configuration, not a hardcoded default.
Scope: the surfaces the framework itself renders. What an agent says in free-form conversation is the agent's own behavior, not something EIF produces.
The benchmark harness runs a real-agent A/B and records the outcome as a machine-checkable contract rather than a headline: one model, three fixtures, six attempts, every attempt completing in both modes. Modes C and D run as integrity contracts, so what they establish is that a run was well formed, not that it was faster.
Command-level timing exists for specific mechanical operations and is recorded with the framework's benchmark evidence. Nothing measures how long a person spends writing or reviewing code.
Scope: this page makes no efficiency or task-quality claim anywhere, and it will not until a study exists that carries one. Six attempts against no baseline and no control group is not that study.
Cloning the repository gets you the ontology, the schemas, the
governance docs, the eifctl package and one
reproducible vertical slice.
eifctl on your PATH, from a cloneYou need Python 3.11 or newer and Git. Every line below is typed into a terminal, from whichever directory you keep projects in. Pick the one that matches your shell.
git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python3 -m venv .venv && source .venv/bin/activate
pip install .git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python -m venv .venv; .\.venv\Scripts\Activate.ps1
pip install .
The separator is ; and not &&:
Windows PowerShell 5.1 parses && as an error.
git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python -m venv .venv && .venv\Scripts\activate.bat
pip install .
.venv is a throwaway Python environment that
belongs to the clone, so nothing here touches the Python you
already use. And the lone . on the last line is
not a typo: it names the directory you just cloned into,
which is where pip reads the package from.
One line, the same on every platform, with the environment from step 01 still active.
eifctl init --project-name <name> --instance-path <path> --locale en--project-name--instance-path. works if
you are already standing in it.
--localeuk is the only other language that ships.
In the reference walkthrough, the bundled demo seeds and retrieves real knowledge, makes one retrieval-informed change, and verifies it with a real test that fails before the change and passes after it. It then closes the session in whichever language the instance config declares. That run declares Ukrainian, because a closeout rendered in English would have proved nothing about the locale layer: the point is that the language is configuration, not a hardcoded default.
This is the public extraction of a private framework I use every working day, on my own projects, across different agents and different models. The models change often. The governance around them does not.
Two kinds of experience accumulate at once. What is specific to one repository stays with that repository. What turns out to hold everywhere is promoted once and is there for every project after it. Neither is a chat log, and neither depends on the agent that produced it still being the agent you use.
It moves at the speed the field moves. A methodology that needs rewriting every time a model, an agent or a tool changes is already behind. Adapters absorb that churn, Graphify, RTK and Context7 are optional precisely so no vendor can break the method, and the core stays where it is while the surface around it keeps changing.
Керована методологія для накопичення інженерного досвіду.
EIF перетворює перевірений досвід на операційний інтелект, який можна застосувати знову. Методологія, пам’ять проєкту, дисципліна сесій і навички агента зберігаються між сесіями.
Агенти ШІ вже добре працюють із кодом. Але історія окремої сесії не є стійким інженерним знанням.
EIF задає керований потік навчання: перевірений Knowledge Delta сесії можна класифікувати, перевірити, залишити в проєкті або підвищити до рівня повторно використовуваних правил, сценаріїв роботи, шаблонів і навичок агента.
У EIF Engineering Intelligence означає версійований інженерний досвід і методи, які керують його застосуванням. Вони визначають підготовку, виконання й перевірку наступного завдання. Це більше, ніж місце зберігання знань.
“Навчання” відбувається на рівні системи. Перевірений досвід оформлюють як переглянутий і версійований артефакт. Наступна сесія може його знайти. EIF не змінює ваги моделі, не донавчає LLM і не дозволяє агенту переписувати власні правила безпеки.
EIF відокремлює повторно використовувану методологію, стійке знання проєкту й тимчасовий контекст сесії. Knowledge Delta визначає, чи переходить знання на інший рівень.
Спільна операційна основа для всіх проєктів. Вона містить онтологію, модель повноважень, глобальні правила, сценарії роботи, шаблони та виконувані навички агента.
Як працювати
Архітектура, рішення, доменні факти, інциденти, ризики й локальні правила одного проєкту.
У межах Р2 кілька проєктів може координувати приватний робочий простір. Він вибирає та фіксує спільні правила, навички, сценарії роботи й шаблони в кожному проєкті, але не стає новим рівнем і не володіє даними проєкту.
Що знає ця система
Поточний обсяг і стан роботи, спостереження, припущення, відкриті питання та чернетка Knowledge Delta.
Що відбувається зараз
Вниз. До сесії надходять методологія та попередній досвід проєкту. Це відбувається до початку реалізації.
Вгору. Переходить лише перевірене знання і лише за окремим рішенням у Knowledge Delta. Зазвичай знання залишається на рівні, де виникло.
Схема показує шлях одного пакета через дві сесії. Вона пояснює, що сесії отримують до реалізації, що зберігається після закриття і що наступна сесія знаходить готовим.
Спочатку пошук. Сесія шукає в стійкому знанні попередні уроки, відхилені підходи й повторювані збої. Робота за EIF починається з цього кроку, навіть якщо завдання здається простим.
Пакет зберігає контекст. Якщо робота охоплює кілька сесій, її статут, факти, рішення й дорожню карту фіксують до реалізації. Завдяки цьому сесія 2 не відновлює рішення сесії 1 з нуля.
Закриття відділяє знання. Під час ретро намір звіряють із доказами й фіксують повторювані збої. Knowledge Delta зберігає структурований результат із джерелом. Сирі міркування не стають пам’яттю проєкту.
Підвищення рівня трапляється рідко. Урок виходить за межі проєкту лише тоді, коли застосовний ширше, його джерело й тип перевірені, а власник його прийняв. Більшість перевіреного знання залишається локальною.
Рівень фреймворку містить спільну методологію. Кожен проєкт має окремий репозиторій і власну пам’ять. Перед реалізацією сесії отримують потрібний метод і локальний досвід. Після закриття пакета перевірений урок може піднятися до рівня фреймворку, але лише за явним рішенням. Тоді його можна використати в іншому проєкті, якщо він там доречний.
EIF координує інструменти та агентів, не підмінюючи їх, і зводить знання, повноваження, виконання й докази в одну послідовність, яку можна спостерігати.
У циклі з’являється завдання або питання.
Раніше перевірене знання підвантажується в контекст ще до початку реалізації.
Очікувану поведінку, фактичну поведінку й авторитетність джерела перевіряють окремо.
Необов’язковий граф коду допомагає швидше знаходити потрібне. Він підтримує навігацію, але не замінює джерело.
Робота триває в межах чітко визначеного обсягу, бюджетів і умов зупинки.
Сам факт злиття зміни не доводить її робочу поведінку.
Здобуте знання фіксують у тій самій сесії, а не залишають у чаті.
Перевірене знання стає доступним наступному завданню й наступному агенту.
Файли репозиторію залишаються авторитетним джерелом. Необов’язковий структурний граф допомагає навігації, але не замінює перевірку джерела.
Перед нетривіальною роботою EIF вимагає знайти попередній досвід. Життєвий цикл сесії охоплює підготовку, контрольоване виконання, перевірку й закриття.
Прочитати активні інструкції та вихідні файли, а потім знайти у стійкому знанні потрібні уроки, збої й відхилені підходи.
Обрати одну сесію або execution packet для роботи на кілька сесій. Назвати мету, докази, обмеження, бюджети й умови зупинки.
Відокремлювати спостереження від припущень. Працювати в заданих межах і спиратися на визначені оцінювачі, а не на заяву про завершення.
Записати реальні докази, відкриту роботу й Knowledge Delta. Зберегти перевірене знання, а ефемерний стан сесії видалити.
Рівень сесії є контрольною точкою, а не пам’яттю. Тут можуть бути стан виконання, позначки доказів, відкриті питання й чернетка Knowledge Delta. Сирі міркування ШІ не зберігають, а весь рівень ніколи не підвищують.
EIF задає Bounded Evidence Loop, або обмежений цикл доказів, для ітеративної роботи агента. Він містить явні оцінювачі, бюджети, докази й умови зупинки. Це методологічний контракт. Сам собою він не доводить меншу кількість повторів, вищу якість, нижчу вартість чи надійне автономне завершення.
Прочитати поточне джерело й здобуте знання, що стосується справи. Факти фіксувати окремо від припущень.
Сформулювати найменшу наступну гіпотезу і спостереження, яке її підтвердить або спростує.
Внести одну оборотну зміну або провести один діагностичний експеримент.
Запустити оголошений оцінювач і зафіксувати його реальний результат.
Порівняти очікуване з фактичним. Якщо результат не збігається з очікуванням, зафіксувати стислу сигнатуру збою для порівняння з іншими спробами.
Обрати наступний крок, спираючись на спостереження. Дію, що вже не спрацювала, без нових доказів не повторюють.
Їх оголошують до першої ітерації. Без них агент не ітерує, а просто повторює спроби.
Три способи завершити, і четвертого немає. Кожен називає доказ або межу, через які цикл спинився.
Knowledge Delta фіксує перевірену зміну в знаннях після сесії. Цей артефакт класифікують, перевіряють і залишають у проєкті. Лише за окремим рішенням він стає версійованим правилом, сценарієм роботи, шаблоном чи навичкою агента.
Два цикли, а не один. Внутрішній цикл фіксує результат окремої сесії. Зовнішній порівнює багато сесій і шукає повторювані моделі. Одиничний випадок може бути інцидентом. Повторювана сигнатура збою може вказувати на правило, якого бракує.
Реальна робота дає докази: факт, інцидент, відхилений підхід, ризик або повторюваний метод.
Сесія записує стислий Knowledge Delta разом із тим, що лишилося неперевіреним.
На межі пакета або раз на кілька тижнів зовнішній цикл збирає активність із репозиторію та шукає повторення. Одна сесія не дає достатньо даних для такого висновку.
Приймання й перевірка знань звіряють тип артефакту, джерело, стан, мову, дублювання й посилання.
Проєктне знання лишається на рівні проєкту. Загальний урок доходить до рівня фреймворку лише за явним рішенням.
Наступна доречна сесія знаходить артефакт до початку дії й замикає цикл навчання.
Кожен артефакт є звичайним файлом зі структурованим заголовком. Заголовок містить тип, межі застосування, стан у життєвому циклі, рівень упевненості, джерело та посилання на сусідні артефакти. Ці посилання утворюють граф. Наприклад, рішення вказує на інцидент, що його спричинив, а урок на правило, яким він став.
Факти, рішення, інциденти, граничні випадки, повторювані моделі збоїв та уроки із зафіксованим походженням і станом у життєвому циклі.
Повторно використовуваний робочий процес для планування, виконання, перевірки, пошуку досвіду або впорядкування знань. Це версійовані інструкції, а не прихована поведінка моделі.
Це кероване навчання на рівні системи, а не автономна самомодифікація. Урок можна відхилити, залишити локальним, визнати простроченим або замінити новішим. Локальна навичка агента може спеціалізувати робочий процес, але не може послаблювати правила безпеки фреймворку.
Graphify, RTK і Context7 додають по одній вузькій спроможності. Жоден із них не є самою методологією, і жодного з трьох фреймворк не встановлює.
Якщо інструмент недоступний, EIF прямо про це повідомляє й переходить на резервний шлях. Це пошук у вихідних файлах замість графа, нефільтрований вивід замість стиснення або локальна документація замість запиту в мережу.
Межа даних: локально для структурного видобутку на основі AST. До зовнішнього API він звертається лише тоді, коли семантичне маркування ввімкнули свідомо.
Без нього: агент повертається до пошуку у вихідних файлах і ручного перегляду, без підказок за графом і без оцінки впливу.
Перевірено: метадані D-08 пов’язують відбиток графа з комітом вихідних файлів, версією Graphify, ідентифікатором репозиторію та переглянутою областю аналізу. Справним вважається лише стан fresh. Зміна коду, семантики чи історії вимагає оновлення, а пошкоджений або вимкнений артефакт лишається недоступним.
Межі: перевірено одну локальну версію й один невеликий синтетичний приклад. Результат навігації не оцінювали.
Межа даних: локально, нічого нікуди не надсилається.
Без нього: команди виконуються без фільтрації, а скорочення не фіксується.
Перевірено: RTK 0.43.0 проходить усі 24 перевірки на тестованому хості Windows через власний маршрут rtk rg. Невдала обов’язкова перевірка дає стан degraded. Нефільтрований або невдалий маршрут через проксі фіксується як нульова економія.
Межі: це не твердження про всі платформи чи загальну ефективність.
Межа даних: текст запиту йде в мережу до зовнішньої служби документації. Вихідний код фреймворк не надсилає.
Без нього: агент покладається на локальну документацію або на власні знання з навчання, які можуть описувати іншу версію, ніж встановлена. Про недоступність провайдера повідомляють прямо, а не підміняють її тихо цими знаннями.
Фреймворк його не встановлює. MCP-сервер налаштовують на рівні користувача, поза екземпляром проєкту. EIF не змінює цю конфігурацію. Він дає правила застосування й шаблон для кожного адаптера, а команду провайдера вписує власник.
Перевірено: декларацію, правила застосування й форму шаблона покрито тестами. Реальну поведінку провайдера не тестували. EIF готує конфігурацію для агента, але сам не спілкується через MCP.
Фреймворк уже має вісім робочих спроможностей. Для кожної вказано спосіб перевірки та межі доказу.
Файл wheel із GitHub Releases або pip install . із клону встановлює eifctl. Одинадцять команд охоплюють створення приватного робочого простору й проєктів, підключення, безпечне оновлення двох осей, перевірку, пошук досвіду, формування артефактів і валідацію. Встановлений пакет проходить життєвий цикл робочого простору та синтетичну задачу, а не лише перевірку імпорту.
Межі: пакет доступний у GitHub Releases, але не опублікований на PyPI. Кожна команда створення формує локальний репозиторій, а не GitHub remote. Оновлення кількох проєктів проходить попередню перевірку, але не є однією атомарною транзакцією.
Перед першим записом EIF перевіряє репозиторій. Якщо проєкт уже має власні правила, робота зупиняється до явного рішення власника. У режимі співіснування згенерований блок поступається наявним правилам.
Межі: наявні правила розпізнаються за обсягом і формою файлів, а не за їхнім змістом. Перевірено на синтетичній фікстурі та повторних прогонах проти одного реального приватного репозиторію.
Пошук працює без мережі за індексом проєкту й враховує схему та стан кожного артефакту. Відхилені й замінені артефакти лишаються читабельними, але за замовчуванням не потрапляють у видачу. Стани unparseable, schema-invalid і not-found повертаються окремо. Українські артефакти індексуються нарівні з англійськими.
Межі: це збіг за словами й підрядками, а не пошук за змістом. Зовнішні служби не використовуються. Нічого не виходить за межі машини.
Робота відкривається як сесія або execution packet для кількох сесій. Заздалегідь визначають спосіб перевірки, бюджети на ітерації та віддалені запуски, а також умови зупинки. Докладніше це описано в циклі доказів.
Межі: це контракт, який робочий процес накладає сам на себе. Він задає, чим робота обмежена, а не скільки спроб піде на конкретне завдання.
Вбудований засіб наново обчислює дайджести маніфесту з файлів на диску й звіряє конфігурацію та lock-файл зі схемами. Він також перевіряє активний адаптер, згенеровану точку входу й цілісність маркерів блоку.
Межі: перевіряється саме той пакет EIF, яким ця команда керує. Це не інструмент загальної перевірки цілісності файлів усього репозиторію.
Підтримуються Claude Code, Cursor, Codex і Hermes. Пройдено всі дванадцять упорядкованих переходів між ними. Після перемикання лишається один активний блок EIF, а точка входу веде до правильного джерела.
Межі: адаптерів свідомо чотири. Їхня механіка відрізняється. Cursor постачає правила без перехоплення викликів, а контракти Codex і Hermes блокують команду, але не переписують її.
Пошук, Knowledge Delta, закриття сесії та згенерована точка входу використовують мову, яку задає екземпляр. Українську перевірено нарівні з англійською. Мова є налаштуванням, а не зашитим стандартом.
Межі: це стосується поверхонь, які формує сам фреймворк. Те, що агент каже у вільній відповіді, це його власна поведінка, а не те, що відтворює EIF.
Стенд бенчмарку запускає A/B із реальним агентом і записує результат у машинозчитуваному контракті. Поточний набір охоплює одну модель, три тестові набори й шість прогонів загалом. У кожному режимі успішно завершено три прогони. Режими C і D перевіряють цілісність прогону, а не швидкість.
Хронометраж окремих механічних команд існує й зберігається разом із доказами бенчмарку. Ніщо тут не міряє, скільки часу людина витрачає на написання чи перевірку коду.
Межі: сторінка не заявляє про швидкість чи якість роботи. Шість прогонів без базової лінії та контрольної групи не дають підстав для такого висновку.
Клонування репозиторію дає онтологію, схеми, документи керування,
пакет eifctl і один відтворюваний вертикальний зріз.
eifctl у PATH із клонуПотрібні Python 3.11 або новіший і Git. Кожен рядок нижче вводять у термінал, із того каталогу, де ви тримаєте проєкти. Візьміть той варіант, що відповідає вашій оболонці.
git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python3 -m venv .venv && source .venv/bin/activate
pip install .git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python -m venv .venv; .\.venv\Scripts\Activate.ps1
pip install .
Тут використано розділювач ;. Windows PowerShell
5.1 не підтримує &&.
git clone https://github.com/mike-arbuzov365/engineering-intelligence-framework
cd engineering-intelligence-framework
python -m venv .venv && .venv\Scripts\activate.bat
pip install .
.venv є окремим оточенням Python для цього клону.
Воно не змінює Python, яким ви вже користуєтесь. Крапка
. в останньому рядку означає поточний каталог.
Саме звідти pip встановлює пакет.
Один рядок, однаковий на всіх платформах, поки оточення з кроку 01 лишається активним.
eifctl init --project-name <name> --instance-path <path> --locale uk--project-name--instance-path., якщо ви
вже в його каталозі.
--localeuk.
В еталонному проході приклад додає й знаходить знання, вносить одну зміну та перевіряє її тестом. До зміни тест падає, після неї проходить. Потім приклад закриває сесію українською, як задано в конфігурації. Це підтверджує, що мова є налаштуванням екземпляра.
Це публічна версія приватного фреймворку, за яким я працюю щодня, на власних проєктах, із різними агентами та різними моделями. Моделі змінюються часто. Керованість навколо них лишається та сама.
Досвід накопичується на двох рівнях. Знання про конкретний репозиторій лишається в ньому. Загальний урок можна підвищити до рівня фреймворку й використати в інших проєктах. Обидва рівні зберігаються як артефакти, а не як історія чату.
Інструменти можуть змінюватися без зміни методології. Відмінності між агентами беруть на себе адаптери. Graphify, RTK і Context7 лишаються необов’язковими. Тому ядро не залежить від одного постачальника.
Engineering Intelligence FrameworkЛіцензія Apache-2.0