Apply for a free pilot
HOW ORCHESTRO WORKS

Simple on the surface. A system underneath.

You ask a question. Set a goal. Give it direction. Follow what the Factory does with it.

CHOOSE YOUR DEPTH
  1. 01“Are there new product bugs?”
  2. 02“Build a Factory for this goal.”
  3. 03“How is my backlog?”
  4. 04“Why isn’t this moving?”
  5. 05“What is it doing now?”
  6. 06“Fix this.”
  7. 07“Did this issue come back?”
Open the system ↓
01 /“Are there new product bugs?”

What matters. What is noise. What needs you.

Your domain decides which sources to read. Similar reports can share a work identity; similarity alone does not prove a shared cause.

WHAT YOU SEEUser reportServer logQA reproductionRelated reportDistinct failureONE DURABLE INTERPRETATIONGroup the proven cause.Keep the original evidence.Keep unrelated failures distinct.Illustrative grouping · no live counts
Implemented · domain dependent Technical reference ↗
02 /“Build a Factory for this goal.”

One goal. A work system built around it.

Start with northstar init. It creates a scaffold; the Domain Builder and readiness gates determine what is ready to run.

WHAT YOU SEE
local terminal · scaffold
$ northstar init \
  --dir packs/content-factory \
  --slug content-factory \
  --goal "Build an evidence-based content system"
scaffold→Domain Builder→readiness gates→ready to run
Implemented · governed bootstrap Technical reference ↗
03 /“How is my backlog?”

Show me what matters now.

Actionable work, current execution, evidence waits, owner decisions and outcomes each have a place. A large count is not a measure of progress.

WHAT YOU SEEActionable ↗In progress ↗Waiting for evidence ↗Needs you ↗Delivered ↗Archived / noise ↗each move is a recorded state changeOwner categories · counts come from the selected project
Live private preview · two connected projects Technical reference ↗
04 /“Why isn’t this moving?”

Know the wait. Know the way forward.

Autonomous does not mean never blocked. Know what is blocked, who can resolve it, and which evidence allows work to resume.

WHAT YOU SEE
ILLUSTRATIVE · EVIDENCE WAITWaiting for evidence
Reproduction needed
Affected work
This investigation
Needed
A reproducible failure
Wakes when
New evidence is accepted
Wider scope must be recorded. Independent work continues only when permitted.
parked · wakes on new evidenceother work continues when permitted
Implemented · historical gaps remain explicit Technical reference ↗
05 /“What is it doing now?”

One current task. A reason. Real progress.

See the active executor and the last durable result separately. An alive process can still be making no measurable progress.

WHAT YOU SEE
ILLUSTRATIVE OWNER VIEWRunning
NowInvestigate a startup failure
Why
Only a recorded selection reason
Executor
Observed local worker
Progress
Last durable receipt, not heartbeat
Executor livenessWake scheduleDurable progressalive · no durable progress
Implemented · observed runtime in cockpit Technical reference ↗
06 /“Fix this.”

Your request enters the system. It does not skip the system.

Chat expresses intent. The local Factory accepts or rejects it, converges it with existing work where appropriate, then chooses when it is eligible.

WHAT YOU SEEIllustrative conversation · configured MCP client
Fix this before the release.
ORCHESTROReceived in cloud.Awaiting local materialization.
backlogAfter local acceptance → canonical work identity
The conversation ends. The request remains.
Private preview · client setup required Technical reference ↗
07 /“Did this issue come back?”

Keep the recurrence. Refine the response.

A fix does not erase the problem’s history. New evidence can reopen work and motivate a refinement.

WHAT YOU SEEILLUSTRATIVE LIFECYCLE✓ check passedreopened · same problem, new evidence01Fix recorded02New contradictory evidence03Refinement proposedThe previous fix stays in history.
Implemented · governed learning Technical reference ↗
THE OWNER COCKPIT

Five views. And a time machine.

One screen per question an owner actually asks. The screens below use sample data; the interface is in Italian.

Orchestro owner cockpit, Map view with sample data: What is the Factory doing right now?Sample data
Play the simulationSee real Factories ↗
SAME KERNEL. DIFFERENT DOMAIN PACK.

The project changes. The operating rules don’t.

The pack teaches the kernel what sources, tools, evidence and outcomes mean here.

REAL HISTORICAL DOMAIN

Product / Reliability

Reduce material product risk.
  • Feedback
  • Incidents
  • QA
  • Release evidence
ARVO provided the original reliability experience. Its public cloud view is coming online; no live release-readiness number is implied.
REAL PROJECT · CURRENT READ MODEL

Marketing / Content

Build a compounding content system.
  • Research
  • Writing
  • SEO
  • Publishing
danielepelleri.com has published outputs. Observed execution and measured audience growth are separate facts.
IMPLEMENTED PROOF · NOT A LIVE SALES PILOT

Sales / Revenue

Keep qualified opportunities moving.
  • Pipeline
  • Follow-ups
  • Qualification
  • Revenue outcomes
The cross-domain sales proof exercises the shared kernel. Live CRM connections and commercial outcomes are not claimed.
SHARED KERNELWork · evidence · independent checks · operating rules
THE GOLDEN RULES

Why the answer can be trusted.

01

One project identity

Content work stays with Content. Switching to ARVO must change every read.
UNDER THE HOODProject predicates + assertScopeRead the implementation ↗
02

One execution seat

A second worker cannot simply take the same local seat.
UNDER THE HOODCanonical lease and authority checksRead the implementation ↗
03

Intent is not execution

“Received in cloud” still means the Mac may not have read it.
UNDER THE HOODIntent receipt → subsequent work projectionRead the implementation ↗
04

Merged is not deployed

A merge receipt does not prove the release reached users.
UNDER THE HOODSeparate merge, deploy and verification receiptsRead the implementation ↗
05

The worker cannot certify done

An executor’s “finished” is not an independent verdict.
UNDER THE HOODVerifier boundary and evidence requirementsRead the implementation ↗
06

Waiting is a real state

Missing evidence keeps work parked with a wake condition.
UNDER THE HOODEVIDENCE_PENDING + evidence planRead the implementation ↗
07

A blocked item need not stop everything

Independent work can continue when the authority and selector permit it.
UNDER THE HOODCheckpoint scope, dependencies and eligibilityRead the implementation ↗
08

Cloud guides. Local executes.

Your phone reads state; your machine operates the repository.
UNDER THE HOODPublisher + intent pull + canonical intakeRead the implementation ↗
09

Configured is not live

A configured publisher is not proof of a fresh observation.
UNDER THE HOODObservation timestamps and stale stateRead the implementation ↗
10

Done must reconcile

External delivery and local lifecycle must agree.
UNDER THE HOODCanonical closeout and reconciliationRead the implementation ↗
THE COMPLETE LOOP

Three flows. One project history.

Cloud holds observations and intent. The project’s local Factory owns execution and durable evidence. No chat session becomes the source of truth.

Observe

  1. 1Sources
  2. 2Domain adapters
  3. 3Canonical evidence
  4. 4Cloud read model
  5. 5Web / MCP readback

Direct

  1. 1Chat client + MCP
  2. 2Cloud intent
  3. 3Local pull
  4. 4Canonical intake / decision
  5. 5Eligible work

Execute

  1. 1Backlog / roadmap
  2. 2Selector + Governor
  3. 3Local executor
  4. 4Independent verifier
  5. 5Ledger / governed learning

Now see a real Factory.

Current observations, with their age and limits made visible.

Open Live Factories →Explore bounded experiments & deeper examples ↗