OROTOV is an Engineering Control Plane for teams that build software with coding agents. It connects approved requirements and decisions to issues, repository activity, checks, and evidence, so a team can see what was claimed, observed, and verified.
For teams building software with coding agents
Keep AI coding work connected to the decisions and tests that define done.
OROTOV connects approved requirements and engineering decisions to coding-tool work and its evidence. GitHub observation is an operator-configured pre-GA pilot.
OROTOV does not write code. It connects approved work to what your engineers and coding agents change.
Your first workspace with one active user is free. GitHub observation requires an operator-configured pre-GA pilot.
Connected work recordOROTOV
IntentApproved requirements and decisions
ExecutionIssue work and linked changes
EvidenceSource and confidence kept together
A status does not stand in for evidence.
Where OROTOV sits
Connect approved work to the code changes and evidence that follow.
OROTOV connects approved work to available evidence while your team keeps its existing repository and coding tools. GitHub event observation requires operator setup for the pre-GA pilot.
Your team sets the direction
- Requirements
- Scope
- Decisions
- Acceptance criteria
People approve the requirements, decisions, and acceptance criteria that guide the work.
OROTOV connects the work
- Issue context
- Decisions
- Dependencies
- Evidence provenance
One workspace links issues and decisions to available evidence. GitHub activity requires an operator-configured pre-GA pilot.
People and agents implement
- Coding agents
- Code changes
- Tests
- Reviews
Engineers and coding agents work in their existing tools. OROTOV does not edit the repository or write code.
The record shows what is known
- Linked changes
- Evidence with sources
- Open gaps
Claims, connector observations, and independent checks remain distinct, so a status does not stand in for evidence.
Engineering drift
AI coding agents make changes quickly. Requirements and decisions still need to follow each change.
Engineering drift is the difference between approved intent, later decisions, implemented changes, and evidence of the result. It can happen in any software project. More parallel agent sessions make the differences harder to spot by memory alone.
01
“We already made that decision.”
A new agent session starts without the earlier decision. The team has to find the discussion and explain it again before work can continue.
02
“This solves a different problem.”
The code works, but its behavior does not match the requirement the team approved. Review has to trace where the interpretation changed.
03
“What proves this is done?”
A status changed, but the issue has no linked commit or passing test required by its lane policy.
04
“Why did this change reach those files?”
A focused task expanded into adjacent code without an agreed reason or updated scope.
05
“Which record reflects the current code?”
The specification, board, decision history, and repository describe different states. Someone has to compare them by hand.
What OROTOV does
Define. Preserve. Govern. Verify.
These steps keep scope, decisions, board state, and evidence connected while the team works. OROTOV records evidence from normal engineering activity rather than asking people to create a separate report.
Define
Put acceptance criteria beside the work.
A story is split into issues with explicit requirements, test expectations, and dependencies. The team can review the scope before an engineer or agent starts implementation.
Preserve
Keep decisions with the issues they affect.
Record the reason for a technical choice against the relevant work. A later session can query that context over MCP instead of relying on an old prompt or a hard-to-find chat.
Govern
Apply the board policy before work closes.
People and agents claim issues on the shared board. OROTOV refuses a move to Done when the issue lacks its required linked commit, passing test, or resolved dependency.
Verify
Keep each record tied to its source.
People and agents can report what they did. Connectors observe repository artifacts, and independent systems can verify outcomes. The source determines the evidence level.
Board
Stream MCP tool responses
Stream get_available_issues and get_issue_context so large agent contexts stop timing out on connect.
60% complete
Issues · STR-13 of 5 complete
- ISS-111Stream get_available_issuesDone
- ISS-112Stream get_issue_contextDone
- ISS-113Chunked SSE transportDone
- ISS-114Backpressure on slow clientsNew
- ISS-115Timeout regression suiteNew
ISS-114what this issue carries
Acceptance criteria
- A slow consumer never stalls the writer for other clients
- Backpressure is observable in the event stream, not inferred from timeouts
Depends on
ISS-113Chunked SSE transportresolved
Decision
D-486Stream over SSE rather than chunked JSON, so a dropped client cannot wedge the writer.
Evidence
- observedchecks passed on PR #482connector:github
- claimedtimeout suite green locallyagent:orotov-swe-01
Reviewing example work and its evidence
- I
- E
- V
- R
- K
Example workspace data plays in your browser. Filter the board, select a story, and use approval controls to change the local demo state. The scripted approval does not change a customer workspace or represent a real approval; actual review and approval stay with the team. GitHub observation is an operator-configured pre-GA pilot.
One feature, end to end
How one approved feature moves through OROTOV.
Engineers and agents still write the code, and people still approve the outcome. OROTOV keeps the scope, decisions, and evidence beside the work as it moves.
The team approves the scope
A story is divided into issues. Each issue states the behavior to deliver, how the team will check it, and what it depends on.
In OROTOV: Stories, issue specs, dependencies
The team records decisions
When a decision changes the approach, record it against the work it affects so later contributors can find the reason and its status.
In OROTOV: Decisions linked to work
An agent claims an issue
A supported coding tool connects over MCP with a workspace-scoped key. The agent can read the issue and record its work on the same board as the team.
In OROTOV: MCP, workspace key, claim and dispatch
The work leaves a trace
Commit references, test cases, and connector events can be linked to the issue. Each evidence record keeps the source that produced it.
In OROTOV: Linked commits, test cases, evidence source
The board checks its completion rule
OROTOV refuses to move an issue to Done while a required commit, passing test, or dependency is missing. Labeled architecture, security, and performance work also needs a recorded decision.
In OROTOV: Lane policy on the OROTOV board
The next contributor reads the history
Issue links, decisions, and evidence remain in the workspace for the next person or agent to inspect before continuing.
In OROTOV: Workspace history, decisions, MCP
The fair question
When does a shared document and issue tracker stop being enough?
For a small change handled in one session, a document and issue tracker may be all you need. OROTOV helps when work spans sessions or agents and you need the decision, implementation, and evidence linked.
A document is separate from the issue it explains.
OROTOV records a decision against the story and issue it affects. A coding tool can query that issue context over MCP before it starts, and the reviewer can see which decision the work followed.
A document cannot check a board transition.
The OROTOV board checks lane requirements before an issue moves to Done. If a required commit, passing test, or dependency is missing, it refuses the transition and identifies the gap.
A written claim still needs a source.
OROTOV records who supplied evidence and how it was obtained. A human or agent claim remains Claimed. A connector observation or independent check supplies stronger evidence.
Separate agent sessions cannot see each other by default.
Agents and people can work from the same board. Issue claims and handoffs stay in the workspace so the next contributor can inspect what happened.
Evidence has provenance
A claim and an independent check are different records.
OROTOV currently records Claimed, Observed, and Verified evidence. Each record keeps its source. A person or agent cannot raise its own claim to an observed or verified level.
- L0People and agents
Claimed
A person or agent reports what happened. OROTOV keeps the claim and its source, but does not treat it as independent proof.
- L1Connectors
Observed
A connector records an artifact in its source system, such as a commit, pull request, review, or check run.
- L3Independent systems
Verified
A trusted system such as CI confirms an outcome and links that result to the work.
The model also defines L2, Correlated, which links an observed artifact to the intent it serves. That level is specified and is not yet implemented, so it is absent from the ladder rather than quietly assumed. Detection today covers evidence drift, where work reaches a terminal state below the evidence its lane requires; the other drift types are roadmap, and the use cases page names each one.
For people and agents
Give coding agents approved work and keep the evidence reviewable.
An agent can read assigned work and record activity through a supported MCP connection. A workspace-scoped key limits the connection to its workspace. People review the result, and an agent-submitted claim stays separate from connector observations and independent checks.
- A coding tool can check a lane requirement before it asks the board to close an issue.
- Evidence submitted by a person or agent stays Claimed until another source observes or verifies it.
- People and agents use the same board, and issue handoffs remain visible in the workspace.
Example: check_lane_requirementsMCP · REST
{ "issue_id": 114, "target_status": "Done" }
// illustrative response
{
"allowed": false,
"missing_artifacts": [
{ "type": "test_case", "description": "Add a passing test case" }
],
"violations": [
"Done requires at least one passing test."
]
}The idea underneath
What does “Engineering, Reconciled” mean?
A software change has an approved purpose, an implementation, and evidence about its result. Engineering drift grows when those records no longer agree. OROTOV links the records so a team can inspect the difference.
An Engineering Control Plane connects approved engineering intent with observed work. OROTOV records a difference and routes unresolved work to a person or agent to review.
OROTOV works alongside the team's repository, issue tracker, and coding tools. It does not replace them or write code.
- 01
What the team approved
Intent
Stories, issues, specifications, acceptance criteria, and recorded decisions define the requested work.
- Stories
- Issues
- Decisions
- 02
What people and agents changed
Execution
Commits, pull requests, reviews, and agent activity connect back to the issues they address.
- GitHub pilot
- Agents
- MCP
- 03
What a source can show
Evidence
Claims, connector observations, and independent checks retain their source and evidence level.
- Claimed
- Observed
- Verified
- 04
What is running in production
Reality
Deployment state and production behavior are part of the model, but production observation is not a current connector capability.
- Roadmap
- 05
Why the system is shaped this way
Knowledge
Linked work, decisions, and evidence give people and connected agents context they can query.
- Workspace history
- MCP
Scope
What OROTOV is not.
These boundaries define what the current product does and where your existing tools remain in charge.
OROTOV does not generate code
Your engineers and coding agents implement changes in their existing tools. OROTOV connects to that work through scoped integrations and MCP.
Your repository stays in control of code
The repository remains the source for code changes. The GitHub connector observes configured events during the pre-GA pilot; OROTOV does not push commits or rewrite history.
The board records work and evidence
Issues can carry specifications, dependencies, decisions, and evidence. A lane policy checks completion on the OROTOV board; it does not gate your CI or merge queue.
People approve and remediation stays accountable
OROTOV can detect a gap and create work for a person or agent to claim. It does not silently change customer systems or approve its own findings.
Integrations
Connect coding tools and review configured repository events.
Coding agents use MCP to read workspace context and submit work with a scoped key. Signed GitHub events require an operator-configured pre-GA pilot. Your code stays in your repository.
GitHub
The connector is designed to observe signed push, pull request, review, and check events. Live use requires an operator-configured GitHub App and remains pre-GA.
Operator-configured pilotMCP
Supported coding tools connect to the OROTOV workspace with a scoped key through MCP.
Available@orotov/connect 0.1.0
The stable npm package creates MCP configuration for supported coding tools.
Stable packageorotov-cli 0.1.0rc1
The Python CLI is a PyPI release candidate. Install the prerelease or run it from the repository source.
Release candidate
Who it is for
For engineering teams that need agent work to stay traceable.
OROTOV fits technical founders, engineering leaders, and delivery teams running coding agents on shared software projects.
Several agents on one codebase
Keep issue claims, decisions, and handoffs in one workspace so parallel sessions can inspect what another contributor has already established.
Projects that outlast a prompt
Carry requirements and technical decisions across weeks of work instead of rebuilding project context at the start of each session.
Changes with explicit review rules
Set acceptance criteria and lane requirements before implementation. The OROTOV board checks required artifacts before it marks an issue Done.
Completion tied to evidence
Keep a person or agent claim distinct from a connector observation and an independent check.
Teams where people approve outcomes
Let agents work on assigned issues while people retain scope, review, and approval authority.
Pricing by workspace and active users
One workspace is free for one active user. Additional workspaces cost $5 per active user.
The first workspace with one active user is free. $5 per active user per workspace each month.
SoloFree
$0first workspace, 1 active user
Use the first workspace to connect a coding tool and track one team's work.
Per active user
$5per active user, per workspace / month
$5 per active user per workspace each month. Members are counted separately in each workspace.
- First workspace + 1 active user: $0
- Additional solo workspace: $5/mo
- Managed workspace: $5 per active user, per workspace/mo
- 2 active users: $10/mo
FAQ
Frequently asked questions
No. OROTOV does not write code or run its own model. Your engineers and coding agents do the implementation in the tools they already use. OROTOV keeps the work and its evidence connected.
Technical founders, engineering leaders, and delivery teams use OROTOV when coding agents work on shared or long-running software projects and the team needs decisions, requirements, and proof to stay connected.
No. Your repository remains the record of code changes, and your team keeps using its coding tools. OROTOV connects approved work with available evidence; GitHub events require an operator-configured pre-GA pilot.
A supported MCP client connects to the hosted OROTOV endpoint with a workspace-scoped key. The stable @orotov/connect package helps configure supported coding tools.
Yes. People set scope and approve outcomes. OROTOV detects evidence drift and creates work for a person or agent to claim. It does not change customer systems automatically. Evidence submitted by a person or agent remains Claimed until a connector or independent system supplies stronger evidence.
A workspace stores the engineering information its team adds, including stories, issues, specifications, decisions, commit references, evidence records, and audit entries. Workspace identifiers scope the stored records and queries.
The first workspace with one active user is free. Each additional solo workspace costs $5 per month. A workspace with more than one active user costs $5 per active user per workspace each month.
Keep agent work tied to approved scope and reviewable evidence.
OROTOV connects requirements and decisions to engineering work and evidence. The first workspace with one active user is free.
- GitHub observation requires pilot setup
- Evidence records keep their source
- People retain approval authority