Skip to content

OROTOV for engineering teams

See how engineering teams use OROTOV in their daily work.

Explore the problems engineering leaders, delivery teams, platform operators, and coding agents can address with a shared workspace. Select a role or start with the task you need to do.

Choose a role

Roleapproved scope vs linked evidence

Engineering leadership

See which delivery claims have evidence behind them

A status update tells you what someone reported. OROTOV links issues and decisions with evidence recorded in the workspace. GitHub observations require an operator-configured pre-GA pilot.

Today

Progress depends on separate reports and follow-up questions.

With OROTOV

The workspace links issues to the records that support their status.

What you actually use

  • Evidence drift

    Review missing lane-required evidence and the work routed for follow-up.

  • Decisions

    Find the decision recorded for a piece of work and inspect what followed.

  • Compliance

    Export workspace-scoped records when a reviewer needs them.

State reconciled:
Issue status, recorded decisions, and available evidence
Drift reduced:
Completion status without the lane evidence it requires
Supported workflow:
Review evidence provenance and assign unresolved gaps as work.

Inspect the source behind a completion claim.workspace records; GitHub observation requires pilot setup

Review evidence drift
  • 01

    What work is missing evidence?

    Review evidence drift findings and the lane requirements the issue still lacks.

  • 02

    Did the team follow the recorded decision?

    Open the decision and its linked work to inspect the implementation trail.

  • 03

    Can I share a record outside the workspace?

    Generate the workspace-scoped compliance export and share it through your approved process.

Roleissue requirements vs completion evidence

Delivery teams

Check the lane rule before an issue moves to Done

Write the expected result and required evidence on the issue. The OROTOV board checks its lane policy before Done; this does not gate a repository merge.

Today

Teams reconstruct completion evidence after a status changes.

With OROTOV

The board checks its own completion rule and names any missing artifact.

What you actually use

  • Board

    People and agents work from the same issues and lane requirements.

  • MCP connection

    Connect supported coding tools with a workspace-scoped key.

  • Decisions

    Record the reason for a change beside the work it affects.

State reconciled:
Issue criteria and artifacts linked during implementation
Drift reduced:
Board status that does not meet its lane requirements
Supported workflow:
Check requirements before Done and route missing evidence to accountable work.

Keep a missing requirement visible on the issue.the board checks its own lane policy

See the pilot workflow
  • 01

    Which artifacts can a lane require?

    The board lane policy requires a linked commit and passing test; labeled issues also require a recorded decision.

  • 02

    Does the check block a GitHub merge?

    No. It controls the Done transition on the OROTOV board, not CI or a repository merge queue.

  • 03

    Can an agent claim the issue?

    Yes. Agents can claim assigned work on the shared board; their evidence remains Claimed until another source confirms it.

Roleworkspace access and configured event sources

Platform operations

Keep workspace access and integration setup scoped

Create and revoke workspace keys, manage membership, and review connector setup. The GitHub App and webhook secret remain operator-managed pre-GA pilot requirements.

Today

Credentials and connector setup are difficult to review in context.

With OROTOV

A workspace key reaches one workspace, and connector events retain their source.

What you actually use

  • Security

    Review workspace access controls and the GitHub pilot boundary.

  • Documentation

    Review key handling, GitHub pilot setup, and troubleshooting.

  • Compliance

    Export scoped records without granting broad workspace access.

State reconciled:
Workspace membership, key status, and configured event sources
Drift reduced:
Evidence records whose source needs review
Supported workflow:
Review scoped credentials and inspect the source of each observation.

GitHub observation is an operator-configured pre-GA pilot.

Revoke a workspace key without affecting another workspace.scoped credentials and configured event sources

Read the setup guide
  • 01

    What can a workspace key access?

    A key resolves to the workspace that issued it. Revoke the key if its tool no longer needs access.

  • 02

    Who configures the GitHub App?

    An operator installs the App, sets its webhook secret, and registers the repository for the pilot.

  • 03

    Are repository events written back to GitHub?

    No. The configured connector observes signed events; it does not push code or edit the repository.

Roleapproved work vs actor-reported activity

People and coding agents

Give coding agents workspace context they can query

A supported MCP client can read assigned work and record activity with a workspace-scoped key. The workspace keeps agent claims separate from connector observations and independent checks.

Today

Each new session reconstructs decisions from prompts and documents.

With OROTOV

People and agents can read the same issues, decisions, and handoffs.

What you actually use

  • Board

    Claim an issue and record progress where the team can review it.

  • Decisions

    Read the recorded reasoning before choosing an implementation path.

  • Workflow skills

    Guide coding tools through discovery, planning, and implementation.

State reconciled:
Approved issue context and work reported by each actor
Drift reduced:
Repeated decisions, conflicting context, and unverified completion claims
Supported workflow:
Use scoped MCP tools and keep the source of each evidence record visible.

Keep actor claims separate from independent evidence.MCP access scoped to one workspace

Connect a coding tool
  • 01

    Can an agent verify its own work?

    No. A human or agent source can write Claimed evidence only. A connector or independent system must provide stronger evidence.

  • 02

    Do agents and people use separate boards?

    No. They can work on the same issues, with claims and handoffs recorded in the workspace.

  • 03

    Does OROTOV write code?

    No. The engineer or coding agent makes repository changes in its own tools.

Jobevidence drift in the private pilot

Find evidence gaps

Find issues that closed without required evidence

Evidence drift occurs when a completed issue lacks an artifact required by its lane. OROTOV detects the gap and creates work for a person or agent to claim.

Today

A reviewer finds the missing check or commit after the issue closes.

With OROTOV

A finding points to the issue, its lane rule, and the missing artifact.

What you actually use

  • Board

    Assign and resolve the finding as accountable work.

  • Use cases

    Check which drift detection workflows are available in the pilot.

  • Decisions

    Inspect the decision attached to the affected work.

State reconciled:
Issue terminal state and its lane evidence requirements
Drift reduced:
Required evidence missing from completed work
Supported workflow:
Detect the gap and dispatch it for a person or agent to resolve.

Detection creates work for a person to review.the detector does not change customer systems

See current detection support
  • 01

    Which drift detector is available now?

    Evidence drift detection is implemented in the private pilot. Review and test detection remain pre-GA.

  • 02

    Does OROTOV fix the missing evidence automatically?

    No. It creates a board issue routed through claim and dispatch.

  • 03

    What evidence is required?

    Lane rules define the required artifacts. Current checks include a linked commit and passing test; labeled issues also need a recorded decision.

Jobworkspace-scoped compliance export

Export workspace records

Export the records held in one workspace

OROTOV can package workspace-scoped compliance records for review. The export uses membership-derived access and keeps workspace boundaries in place.

Today

A teammate assembles records from separate tools by hand.

With OROTOV

An authorized member exports the records available in the workspace.

What you actually use

  • Compliance

    Download the available CSV records in a workspace-scoped archive.

  • Decisions

    Review recorded choices and the work linked to them.

  • Board

    Inspect issue context and the evidence attached to it.

Export records with workspace scope applied.access checked against workspace membership

Review security and data handling
  • 01

    Does an export create evidence that was never recorded?

    No. It packages records already held in the workspace; it does not invent artifacts.

  • 02

    Can an export include another workspace?

    No. The compliance export is scoped to one workspace.

  • 03

    What if an item has only a claim?

    The record keeps its Claimed level and source. The export does not promote it.

Jobsupported MCP client and workspace key

Connect a coding agent

Let an agent read the issue before it starts coding

Connect a supported MCP client to one workspace. The agent can query assigned work and record activity without receiving access to other workspaces.

Today

An agent uses whichever prompt or document is available in the session.

With OROTOV

The agent can query issue details, decisions, and dependencies from the workspace.

What you actually use

  • Board

    Find issues available to claim and the work linked to them.

  • Workflow skills

    Guide coding tools through discovery, planning, and implementation.

  • Decisions

    Read choices recorded by the team before implementation.

One key authenticates the tool to one workspace.MCP access does not change evidence provenance

Install the workflow skills
  • 01

    Which tools can connect?

    Supported MCP clients can use the published connector configuration. The skills page lists verified installation paths.

  • 02

    Does connecting an agent make its claims verified?

    No. Agent-authored evidence remains Claimed.

  • 03

    Where does the code run?

    The coding tool edits code in the repository and environment your team already uses.

Joblinked issues, decisions, and artifacts

Carry decisions across sessions

Read decision and issue history before continuing work

Record a decision against the work it affects. People and connected agents can inspect the issue history instead of asking a teammate to reconstruct the rationale.

Today

A new contributor asks colleagues to explain earlier choices.

With OROTOV

The workspace links decisions to issues and their associated evidence.

What you actually use

  • Decisions

    Read a recorded choice and the work that followed it.

  • Board history

    Inspect issues and the decisions linked to their work.

  • MCP connection

    Use supported tools to query workspace history within the key scope.

Keep decision history beside the affected work.evidence comes from normal engineering activity

Read the documentation
  • 01

    Does this replace engineering documentation?

    No. It records decisions and linked work so a contributor can check whether docs and implementation still agree.

  • 02

    Does it verify code written before setup?

    No. Historical records are not backfilled as independently verified evidence.

  • 03

    Can an agent search these records?

    Supported MCP tools can query context within the workspace that issued the key.

Start with one workflow

Choose a small part of the workflow to try.

Start with one issue, a team board, or a coding tool connection. Each path uses capabilities available in the current pilot.

  • Start 01

    One workspace and one issue

    Create the free one-user workspace, write acceptance criteria for a real issue, and review the evidence its lane requires.

    For an engineer evaluating the workflow.

  • Start 02

    A team sharing one board

    Put the work of one team on the board and link decisions, commits, and checks as the work progresses.

    For delivery and platform leads.

  • Start 03

    A coding tool connected over MCP

    Connect a supported tool with a workspace-scoped key and review its claims separately from connector observations.

    For teams already using coding agents.

Capabilities

Browse current capabilities and pilots.

Select a section to review its current scope and availability.

Delivery/board

Board

People and agents use the same issues. The board checks lane requirements before an issue moves to Done.

  • 01Issues can carry commit references, test cases, and check results
  • 02Agents claim work on the team board and leave a handoff trail
  • 03The Done check applies to the OROTOV board, not a repository merge queue

Start with one workspace

Connect one piece of work to its decision and evidence.

The first workspace with one active user is free. Add an issue and review its evidence requirements.

See pricing