Explore in 3DBook a demo
The Analyze wing · For existing systems

Know the system before anyone changes it.

Existing systems are rarely fully documented. The Analyze wing reads yours the way a senior engineer would: the code and the documents around it, the screens people actually use, and the database underneath. You get a written, verified picture of what exists today, with every uncertainty flagged instead of guessed.

For existing systems only. Greenfield projects skip Analyze and start at Plan.Start at Plan

Book a 30-minute demoMeet the agents
REReverse engineer#0114UIUI analyzer#0127DBDB schema analyzer#0153
Reads
Source code, existing documents, the running UI, the database schema
Produces
A verified documentation suite, ready for Plan
Gate
Your team confirms it matches reality

Starting greenfield? There is no existing system to read, so Analyze does not apply: your project starts at Plan, with your goal and briefs.

How it works

Three readers. One verified picture.

Each agent reads a different layer of the same system, and each one writes down what it found. Where two layers disagree, the disagreement is the finding.

Reads

Source code
Existing documents
The running app
Database schema

Agents

REReverse engineerAgent #0114
UIUI analyzerAgent #0127
DBDB schema analyzerAgent #0153

Produces

Technical documentation
Screen & workflow walkthrough
Data model, in plain English
Open questions, flagged

Gate

Your team confirms it matches realityR. Fischer · 09:12
Plan
The agents

Meet the 3 agents.

Each one has a codename, one job and a record of everything it did. These views show a sample project.

REReverse engineerAgent #0114

Reads the code, so nobody has to reverse-engineer it by hand.

Point it at a repository or an upload. It maps modules, call paths and integrations, then reads the specs, wikis and notes you already have and reconciles them with what the code actually does. The result is a documentation suite your team can review in an afternoon, not a quarter.

Reads

  • A repository or an upload
  • Existing specs and notes

Produces

  • Technical documentation suite
  • Module and integration map
  • Gaps and decisions log
Reverse engineer · sample project, illustrative
UIUI analyzerAgent #0127

Walks every screen, the way your users do.

It explores the running application end to end: pages, forms, workflows and the calls behind each action. Every screen is captured and described, so behavior that only lives in the interface is written down before anyone plans a rebuild.

Reads

  • The running app
  • A test account

Produces

  • Screen-by-screen walkthrough
  • Workflow map
  • A capture of every state
UI analyzer · sample project, illustrative
DBDB schema analyzerAgent #0153

Explains the database in plain English.

Connected read-only, or given a schema export, it maps tables, keys and relationships and writes a plain-English account of how the data hangs together. Where the database and the screens disagree, it says so: a delivery note the screen accepts at 500 characters but stores at 255 is flagged, not assumed.

Reads

  • A schema export, or read-only access

Produces

  • Data model and relationships
  • Plain-English data write-up
  • Mismatches, flagged
DB schema analyzer · sample project, illustrative
The gate · Analyze → Plan

Nothing moves on until it matches reality.

Before Plan reads a word of it, the people who know the system confirm the documentation describes what really runs. Anything the agents could not verify stays visibly open.

Gate checklistAnalyze → Plan
  • The documentation reflects the system that really runs
  • Unverifiable behavior is flagged, not assumed
  • Every open question has an owner
  • Your team signs off before Plan reads it
RF
R. Fischerclient architect
Approved · 09:12
Guardrails

What the Analyze wing never does.

  • Read-only, always. Analyze never writes to your code or your database.
  • Behavior it cannot verify is labeled “needs verification”, never smoothed over.
  • Everything it writes is a document you can open, review and keep.
The red thread

One ID, through Analyze.

  1. ScreenOrders list
  2. FlowFind an order
  3. Gap500 vs 255
  4. PlanBRQ-0014

The orders screen nobody had documented becomes a walkthrough, a flagged gap and, in Plan, requirement BRQ-0014: the ID that follows this work all the way to production.

  1. AnalyzeRead the system you already have
  2. PlanTurn the goal into testable requirements
  3. BuildTests first, then the code
  4. StageStand it up somewhere real
  5. VerifyProve it works, requirement by requirement
  6. ReleaseShip it, with a way back
  7. OperateKeep watching, close the loop
See it on a real project

Watch Analyze run, in thirty minutes.

We open Orlian on a live project and walk you through the Analyze wing: what goes in, what the agents produce, and where a person signs. No slides.

Book a 30-minute demoSee it on the campus