Skip to content

A-00: Signal Extraction

Project Context → Mission Brief

Role

A-00 is the first agent in the Phoenix pipeline — and the only one that does not touch the codebase. Its job is to read everything known about the application and produce the mission brief: a structured document every downstream agent reads before beginning their work.

A-00 is not extracting business logic. It is not tracing code. It is building the heads-up — the orientation that lets every agent that follows arrive knowing what they are walking into, rather than discovering it blind.


Inputs

A-00 adapts to whatever exists. The output is always the same.

If documentation exists:

  • Requirements documents, wikis, onboarding notes
  • API specifications, OpenAPI/Swagger definitions
  • Architecture diagrams and design documents
  • Stakeholder-provided context and briefings

If no documentation exists: A-00 scans the system surface directly:

SurfaceWhat it reveals
Route tableWorkflow names — verbs the system responds to
Database schemaEntities and their relationships
Config filesBoundaries — what the system connects to
Job schedulerBackground processes and scheduled tasks
Dependency listTech boundaries and third-party integrations
Folder structureDomain groupings and service boundaries
Test file namesOften the clearest workflow names in the codebase

Either way — same brief format. Forage proceeds identically. Downstream agents do not need to know which path A-00 took, only what it found.


What A-00 Extracts

Four signal types:

Named Processes — Verbs that appear in docs, routes, function names, test names. These become workflow candidates: register, checkout, approve, refund, reconcile. Every verb that describes a system behaviour.

Entities — The nouns. User, Order, Invoice, Product, Cart. They tell agents what workflows operate on and help disambiguate when two routes look similar.

Entry Points — The concrete map: every route, scheduled job, event listener, queue consumer. This is the completeness anchor for A-01. When extraction is done, every entry point should be claimed by some workflow.

Boundaries — External APIs, databases, queues, third-party services. These become the expected terminus points during A-01 extraction. If a call stack does not hit a known boundary, the trace is not complete.


Outputs

_mission.sil — the mission brief

Saved at the project root. Every downstream agent reads it.

CONSTRUCT  signal
ID         _mission
VERSION    1
─────────────────────────────────────────
system:
  E-commerce order management system.
  Handles cart, checkout, fulfilment, and returns
  for a B2C retail operation.

known workflows:
  cart.add, cart.checkout, order.fulfil,
  order.return, user.register, user.login,
  payment.refund, inventory.restock
  expect ~12 workflows total

entities:
  User, Cart, Order, Product, Payment,
  Shipment, Return, Inventory

entry points:
  http:    47 routes
  jobs:    3 scheduled (nightly reconcile, weekly report, daily restock)
  queues:  2 consumers (payment.events, shipment.events)
  events:  0

boundaries:
  Stripe     → payment processing and refunds
  SendGrid   → transactional email (confirmation, shipping, returns)
  ShipBob    → fulfilment and shipment tracking
  PostgreSQL → primary data store

tech surface:
  language:  Ruby
  framework: Rails 6.1
  database:  PostgreSQL 14
  hosting:   Heroku (inferred from Procfile and config/database.yml)

source:
  API docs (partial), route table scan, schema inspection.
  No requirements documents found.

confidence:
  medium — routes and schema were clean; no business docs available.

notes:
  Payment refund logic appears in two places — payment/refunds_controller.rb
  and a background job. May represent two distinct flows. Flag for A-01.
  Inventory restock job references an external ERP system not found
  in the dependency list — confirm before A-01 begins.

Signal .sil files — one per workflow candidate

Saved in /signals/. A-01 reads one signal file per workflow as it begins extraction.

CONSTRUCT  signal
ID         cart.checkout
VERSION    1
─────────────────────────────────────────
type:      workflow
entry:     POST /cart/submit
entities:  Cart, Order, Payment, User
boundary:  Stripe, SendGrid, PostgreSQL
source:    route table, API docs
notes:     High abandonment reported at payment step

UNKNOWN entry points are valid — A-01 will locate them. The signal still helps orient the extraction.


What A-00 Does Not Do

  • Extract business logic — that is A-01's job
  • Trace call stacks — that is A-01's job
  • Draw wireframes — that is A-02's job
  • Invent workflows that have no signal evidence
  • Mark confidence high if the source was thin
  • Produce anything other than _mission.sil and /signals/*.sil files

Human Validation Gate

Before A-01 begins, the AI Software Lead reviews the mission brief:

  • Confirms the system description is accurate
  • Validates the workflow candidate list against known business processes
  • Adds any workflows A-00 could not detect (undocumented legacy behaviour)
  • Confirms boundaries are complete
  • Adjusts confidence rating if needed
  • Clears the notes — resolves or escalates flagged ambiguities

The brief that exits this gate is the map every agent carries for the rest of the engagement.


Why A-00 Exists

Without A-00, every agent discovers the system blind. A-01 starts tracing without knowing how many workflows exist. A-04 designs without knowing the boundaries. A-06 certifies without knowing what was in scope.

The brief does not need to be complete. It needs to be honest. A low-confidence brief with clear notes about what is missing is more useful than a confident brief built on guesswork.

"You are the kid who knows it's an ice cream shop with 12 flavors before walking in. Without you, every agent that follows discovers the system blind. With you, they arrive oriented."


Next: A-01 — Business Logic Extractor →