Divengine StudioEngineering knowledge,
explicit and connected.
Divengine Studio keeps the engineering context of your software: the requirements, decisions, models, code, tests and evidence behind it, as connected, versioned records. The reasoning behind a change can still be followed and checked long after the people, meetings and tools that produced it have moved on.
Code shows what a system does. Rarely why.
Every system is the result of decisions made under constraints. Most of that reasoning is never written down where the next engineer will look for it.
Reasoning stays implicit
Intent, assumptions, alternatives and trade-offs are settled in meetings, chats and people's heads. They shape the system, but they are not recorded as anything a reviewer can open.
Code and documents are not enough
Code holds the outcome of a decision, not the options rejected or the constraint that made it right. Documents drift, and seldom say which requirement, test or version they describe.
Context leaves with people and tools
When people move on or a tool is replaced, its context goes too. Teams then reconstruct intent from code during a change, an incident or an audit, when it is most expensive.
Context, method and platform
The central thesis is simple: engineering knowledge should stay explicit, connected and usable beyond the individuals and tools that produced it. Three different things serve it.
Engineering context
The structured, persistent, scoped and version-aware body of knowledge about an engineered solution: problems, intentions, requirements, decisions, assumptions, trade-offs, models, implementation, validation, evidence and their relationships.
What Studio keeps.
Explicit Software Engineering Method
ESEM is an independent, process-orthogonal method that defines obligations for making engineering reasoning explicit, traceable and evaluable. It does not depend on any tool.
Divengine Studio
The software platform: it lets teams organize engineering artifacts, maintain traceability, preserve history and access engineering knowledge. It works with or without ESEM, and ships with the Unified Process.
What you install.
One change, followed end to end
An insurer wants to give storm-damage claims 60 days instead of 30. In Studio, that change request is not a ticket that disappears when it closes: it is linked to the records it affects, and those records are linked to everything that explains, implements and proves them.
- derives fromBR-0002 · Business ruleClaims are filed within 30 days of the incident
- depends onDEC-0003 · DecisionCount the deadline from the incident date, not from submissionRationale and alternatives considered
- is represented byBPMN diagramClaim intakeIts “Check deadline” task links back to the requirement
- is implemented bySRC-0001 · Repositoryclaims-service,
src/Claims/Deadline.phpIndexed from Git, with extracted code documentation - is verified byTest caseDeadline warning, 5 stepsLast run passed; screenshots and logs kept as private evidence
Impact analysis, before the change
Open CR-0004 and follow what it impacts. From REQ-0001, the typed traces show the rule it comes from, the decision that would have to be revisited, the process model to update, the code that implements it and the test to run again. These links were recorded by people and can carry a rationale, so the list is the one the team agreed on, not a guess from text similarity.
Reconstruction, years later
Someone asks why deadlines are counted from the incident date. DEC-0003 keeps the rationale and the alternatives. The revision history of REQ-0001 shows who changed what and when. Baseline BL-0002 holds the exact revisions, and traces, that were in force at the Lifecycle Architecture milestone, and the test run keeps the evidence of what was verified.
What Studio does not do
It does not invent reasoning nobody wrote down, and it does not decide for you. It makes recorded knowledge persistent, navigable and permission-aware. Delivering these views as bounded, reproducible context for people and tools is on the roadmap.
What Studio keeps, connected in one place
Each module contributes a different part of the engineering context, and they all share the same records, codes, traces, revisions and permissions.
Engineering records & traces
Requirements, use cases, rules, decisions, risks and evidence with codes, lifecycles and revisions, linked by typed traces.
Product →Knowledge & models
Business and system models, BPMN and UML diagrams whose elements link to records, and a knowledge base that knows what it talks about.
Knowledge →Process & baselines
The Unified Process with phases, milestones, readiness, change requests and baselines that freeze the exact revisions agreed.
Process →Validation & evidence
Test plans and runs with frozen snapshots, private evidence and QA issues, and requirements verified by the tests that cover them.
Quality →Code, docs & schemas
Git repositories, code documentation extracted from any language and database schema snapshots, next to the records they implement.
Code & data →Coordination
Projects, Kanban boards and timesheets for the day-to-day work, linked to the engineering records it serves.
Work →Not another IDE, forge or tracker
Studio is not only project management, a document repository, a diagram editor or an AI product. It is where the engineering context lives, next to the tools your team already uses.
What Studio is
- A platform for explicit, connected and versioned engineering records
- Server software you install, on premises or in your cloud
- A reader of your Git repositories, code documentation and database schemas
- Free software you can extend like any Drupal site
What Studio is not
- Not a SaaS: there is no account to rent, it's yours
- Not a code editor nor a replacement for your Git host or CI
- Not the method itself: ESEM and Studio are independent
- Not a black box: traces are explicit, never inferred
From connected records to delivered context
The roadmap builds on the same explicit records. None of these capabilities exists yet; each is designed and reviewed in the open before it is built.
Engineering context delivery
Bounded, permission-aware and reproducible context views of a Development, a baseline or a change, for people and for MCP clients.
Modeling Foundation
A semantic model repository with UML, BPMN, IFML, ArchiMate, DMN and CMMN extensions, beside today's diagram modelers.
Discovery & evaluation
Investigations, questions and conclusions linked to the process, and an optional evaluator for ESEM obligations.
Your engineering knowledge, on your servers
Studio is a Drupal 11.4 distribution with its own web installer. Install the code with Composer, create a PostgreSQL database, open the installer in your browser and choose whether to add the optional MCP integration.
- GNU GPL v3: use it, study it, change it, share it
- PHP 8.4 and PostgreSQL 16 or newer
- Roles from tester to Studio Manager, access by Development membership
git clone https://github.com/divengine/studio.git
cd studio && composer install
createdb -O studio studio
psql -d studio -c 'CREATE EXTENSION IF NOT EXISTS pg_trgm'
# set the private file path in settings.php, then open
# https://studio.example.com/core/install.phpFrequently asked
What is engineering context?
The structured, persistent, scoped and version-aware body of knowledge about an engineered solution: its problems, intentions, requirements, decisions, assumptions, trade-offs, models, implementation, validation, evidence and the relationships between them. Studio keeps that knowledge as records with codes, revisions and typed traces.
Is Studio an implementation of ESEM?
No. The Explicit Software Engineering Method (ESEM) is an independent, process-orthogonal method that defines obligations for making engineering reasoning explicit, traceable and evaluable. It does not require Studio, and Studio does not require it. Studio provides records, traces, revisions and baselines that a team following ESEM, or any other method, can use. An optional ESEM evaluator is a roadmap item, not a shipped feature.
Does Studio infer decisions or traces automatically?
No. Traces are explicit, typed links recorded by people, and decisions are records written by the people who make them. Studio keeps the history and makes the links navigable; it does not guess reasoning that nobody recorded.
Is Divengine Studio a SaaS?
No. Divengine Studio is software you download and install on your own server, on premises or in your cloud. Your engineering knowledge stays in your infrastructure, under your control.
Is it really free?
Yes. Divengine Studio is free and open source software under the GNU GPL v3. You can use it, study it, change it and share it.
What do I need to run it?
A Linux server with PHP 8.4, PostgreSQL 16 or newer with the pg_trgm extension, Composer 2, Git and a web server such as Caddy, nginx or Apache. Studio is a Drupal 11.4 distribution with its own web installer.
Does it replace Git, my CI or my issue tracker?
No. Studio runs alongside the tools you already use. It reads your Git repositories, receives database schema snapshots and extracted code documentation from your pipelines, and can expose them read-only to AI assistants, but it is not a forge, a CI server or a replacement for your tracker.
Can AI assistants use it?
Yes, optionally. A read-only MCP server lets connected assistants read records, traces, diagrams, source code, extracted code documentation and database schemas of the Developments their service account may see. Approvals and test results stay with people.
Why Drupal?
Drupal gives Studio a mature, secure and extensible foundation: entities, revisions, workflows, permissions, an API and a large ecosystem. Studio adds the engineering model on top, following Drupal's own practices, so it is easy to extend and maintain.
Keep the why next to the what
Install Divengine Studio on your own server and give your team one place where intent, decisions, models, code and evidence stay connected.