Where TRACE comes from

The five governing principles ask, for each unit of AI-assisted work, what happened, what it was checked against, who accepted it, what was allowed to advance, and whether a correction worked.

TRACE is defined in a working paper, not yet published:

Amirhossein (Miros) Zohrehvand (Leiden University) and Aldona Kapačinskaitė (INSEAD), Governing AI-Assisted Research with Principles from Computer Science, working paper, 2026.

The paper argues that AI-assisted research needs principles for organizing workflows more than further workflows shared as recipes: sequences of prompts, steps and tools that do not say how to check the outputs or who may accept them. It starts from an older coordination problem: software teams have long had people and machines produce separate pieces of work and integrate them into one result. It draws the five principles from software engineering and security research on how such teams track, review, accept, control and evaluate that work, and carries them over to AI-assisted research. There they govern the process between adopting AI and the research outcome.

The architecture keeps researchers in control of decisions and requires explicit acceptance. When acceptance is delegated to an agent, a named researcher remains accountable. The paper’s claims are modest: the records make gaps visible without establishing that every required action occurred, and whether the workflow improves research outcomes remains an empirical question.

1. T

   Track records

   Record what happened, in what order, and why, and keep the work’s current state visible to everyone who uses it.

   Shared version history, and a trace record for every agent session that commits work, linking the captured instructions to the agent’s choices, with their reasons, and to the changes they produced.

2. R

   Review against sources

   Compare an output with an explicit criterion or another source before others rely on it. Sources include the data and the logic of a claim, not only citations.

   Checking records that name the candidate, criterion, sources, method, outcome and limits; model objections must quote the text, and the quotes are checked.

3. A

   Accept independently

   Give each unit of work an owner, and separate producing the work from the decision to accept, return or refuse it, taken by an actor other than its producer. A researcher who authorizes an agent or a process to accept stays accountable for what it accepts.

   Decisions by a person, or by an agent or process under a named researcher’s authority, recorded against the version they cover and apart from model critique.

4. C

   Control transitions

   Check and authorize outside material and AI output before they enter the manuscript, the project’s data or its standing instructions.

   Intake records of who admitted, returned or refused outside material, which waits apart until then, and transition records for drafts moved into the shared manuscript and instructions adopted as defaults.

5. E

   Evaluate corrections

   Take what review or use finds back into the work, and keep a detected error open until the team has checked that the correction worked.

   A defect ledger linking findings, claimed fixes, recurrence and targeted rechecks of the original problem, one for each output a finding reaches.

How the principles were derived

The authors follow the way Elinor Ostrom derived her design principles for governing shared resources such as pastures, forests and irrigation water (Governing the Commons, 1990). The specific rules of the communities she studied differed from case to case and could not explain success across settings, so she stated what the enduring institutions shared. The authors apply the same logic to software engineering and security research, whose central problem has long been joining what people and machines produce into one coherent piece of work. They read the field’s papers for what teams actually do, kept the actions that carry over to research teams working with AI, and asked what those actions have in common.

The derivation has six steps, and the table shows how many papers and actions remain after each. The search covered fourteen software engineering and security journals and conferences from 2000 to 2026, and literature reviews on software teams, collaboration or development practices in the rest of Scopus. Screening kept the papers whose subject is “a recurring, nameable way a development team organizes its joint work”. Two language models then read each paper separately (the full text where it could be obtained, otherwise the title and abstract), with no list of practices or principles given to them in advance, and listed every action it reports or recommends, each with a quotation that a script checked against the paper. The same two models kept an action only when both judged that it applies to research, to work with AI, and to work that one party produces and another uses, builds on or answers for. Each kept action was restated as one plain sentence about what it does, without the practice’s name or software terms, so that “code review in GitHub” and “checking a draft analysis” become the same kind of action. The restated actions were clustered by meaning into activities, and two models sorted the activities into broader families.

Step	What remains	Papers	Actions
1. Search	Records found: 5,978 in the fourteen outlets and 4,344 in the rest of Scopus	10,322
	Papers kept by screening	1,565
2. Extraction	Papers with at least one action, and their actions	1,324	16,272
3. Selection	Actions that apply to research and to work with AI	966	5,866
4. Selection	Actions that also concern one party’s work becoming another’s input	662	2,265
5. Restatement	Actions restated by what they do	661	2,258
6. Grouping	Activities (clusters of near-identical actions)		56
	Families with at least 2 per cent of the actions and ten papers		8
Arrangement	Principles		5

The first sorting model formed eight families, and the derivation uses those eight. The authors then arranged the families under five principles, by their reading of how each carries over from software to research, where the work is more exploratory and less structured. They folded stakeholder communication into track records, because a research team’s stakeholders during the work are mainly its own members and coauthors, so keeping them informed is a by-product of keeping the shared state of the work visible. They divided the largest family, collaborative peer review, by what its activities do: examining the work is review, deciding on it is acceptance, checking it before it is added is control, and fixing what was found is correction. They set aside one family, knowledge sharing and newcomer onboarding (4.0 per cent of the actions), because it happens mainly once, at entry, rather than throughout the work. With these choices, the five principles cover 2,167 of the 2,258 restated actions (96 per cent).

What the derivation can and cannot show

The authors test the derivation against its own choices and state its limits.

• Models did the reading and sorting. Models did every reading and sorting step, and no person has yet coded a sample of the same material.
• A second model agrees only partly. A second model sorted the same 56 activities into nine families, which can be arranged under the same five principles with similar shares. Of the actions the first model places under the five, the two arrangements put only 61 per cent under the same principle, so the lines between neighboring principles depend on the model. Both models come from one developer and may share biases from their training, so their agreement shows that the families do not hinge on one of them, not that they are right.
• The arrangement into five is the authors’. Models formed the families; arranging them under five principles is the authors’ reading. An earlier derivation from the records of the same search took a longer route, starting from the practices the papers name rather than the actions they report, and its results also fall under the same five. The two routes differ in their unit, their selection rule and their models. The authors had said beforehand that they aimed for five or six principles, and the earlier route’s requirements and the resolution of its disputed cases were theirs, as the arrangement is in the main derivation, so the agreement shows that the five hold across routes, not that a model recovers them unaided.
• The five cover the kept actions, not good teamwork in general. The 96 per cent is a share of the actions the selection kept. Relaxing the selection shows what it keeps out: the practices of producing software as such, and planning, communication and training within a team. The principles presuppose these conditions of teamwork rather than govern them, and they concern work that one party produces and another relies on.
• The wider search does not decide the families. Restricting the papers to the fourteen outlets leaves all eight families above the thresholds and changes each principle’s share by at most 3.4 percentage points. The wider search adds actions to the families but does not decide which of them pass the thresholds.
• Nothing yet shows that the principles improve research. The literature shows which actions software teams report, not that they work, and not that they work in research. The transfer to research is the authors’ argument, and there is no evidence yet that following the principles improves research outcomes.

How TRACE-OS implements them

TRACE states principles rather than rules or best practices tied to specific technologies. AI models and tools change quickly, and a rule that prescribes a particular tool or sequence of steps becomes outdated with them. Just as Ostrom’s design principles held across communities whose specific rules differed, the TRACE principles state what a team needs to do, whatever tools it uses.

TRACE-OS is one implementation, built for teams that work with AI agents in a shared Git repository, which the authors make available to other researchers. Other teams can build their own. Its development repository is the paper’s demonstration, performing the principles rather than describing them.

Each principle has a skill named for it, so the letter stays visible in the workflow: trace-state for T, trace-review for R, trace-acceptance for A, trace-ctransition for C and trace-evaluate for E. trace-check reads all five back. These six skills are the governance routines: they specify which instructions, choices, checks and decisions to retain, while research skills, such as the claim audit or literature processing, guide the substantive work.

Onboarding is not a sixth principle, but it is a design choice of TRACE-OS. AI agents keep no long-term memory, so the implementation onboards them constantly: every agent in a project starts each session from the same written instructions on how TRACE-OS and the principles work, beginning with AGENTS.md.

The kit has changed its own name, and TRACE has kept its: the five principles, the trace record, the trace-* skills and the scripts.

For what each principle asks of you, see The five principles.