orchestro.
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.

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 SEE
User reportServer logQA reproductionRelated reportDistinct failure
ONE DURABLE INTERPRETATIONGroup the proven cause.

Keep unrelated failures distinct.
Keep the original evidence.

Illustrative grouping · no live counts

WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Declared sources
  2. 02Normalize signals
  3. 03Stable identities
  4. 04Evidence & causal families
  5. 05Material work
  6. 06Owner answer

Reliability adapters can interpret feedback and production evidence. Family membership needs canonical evidence; a distinct database failure must remain distinct. Raw inputs retain their provenance. No source is universally connected by default.

Implemented · domain dependentTechnical 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"
WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Goal
  2. 02Domain manifest
  3. 03Capabilities & sources
  4. 04Tools & permissions
  5. 05Evidence & verification
  6. 06Initial work
  7. 07Readiness

The pack defines work types, measurable goals, source adapters, guardrails, autonomy and executor posture. Bootstrap reconciles capabilities against the canonical map before READY. Credentials and integrations still require configuration. The original Content Factory was manually configured.

Implemented · governed bootstrapTechnical 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 SEE
Actionable
In progress
Waiting for evidence
Needs you
Delivered
Archived / noise

Owner categories · counts come from the selected project

WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Project identity
  2. 02Latest snapshot
  3. 03Work projection
  4. 04Receipts + intents
  5. 05Lifecycle reconciliation
  6. 06Owner view

Every cloud read is scoped to the selected project. The local publisher derives work state from canonical backlog and receipts. An accepted request is not execution. ARVO and Content never share a backlog merely because titles look alike. Unknown or stale state stays visible.

Live private preview · two connected projectsTechnical 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 WAIT

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.

WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Canonical interruption
  2. 02Category
  3. 03Item / mission / Factory scope
  4. 04Required action or evidence
  5. 05Resolution receipt
  6. 06Resumption evidence

OWNER, EXTERNAL, PROVIDER, EVIDENCE and RUNTIME / INFRA are different causes. Scope is shown only when recorded. Older receipts may not establish mission scope or human involvement. A fallback receipt proves an executor handoff; later progress must prove that work continued.

Implemented · historical gaps remain explicitTechnical 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 VIEW
Running

Now

Investigate a startup failure

Why
Only a recorded selection reason
Executor
Observed local worker
Progress
Last durable receipt, not heartbeat
WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Checkpoint
  2. 02Actionable work
  3. 03Selector
  4. 04Authority check
  5. 05Single execution seat
  6. 06Executor
  7. 07Durable receipts

The watch wakes the Factory. The selector chooses eligible work within authority. The execution seat protects the local loop. Executor liveness, wake schedule and durable progress are separate signals. Selection rationale is shown only when published, never invented from a title.

Implemented · observed runtime in cockpitTechnical 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 SEE

Illustrative conversation · configured MCP client

Fix this before the release.
ORCHESTROReceived in cloud.
Awaiting local materialization.
After local acceptance → canonical work identity

The conversation ends. The request remains.

WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Chat / MCP intent
  2. 02Cloud receipt
  3. 03Local pull
  4. 04Canonical intake
  5. 05Selection & execution
  6. 06Independent verification
  7. 07Cloud readback

MCP can append project-scoped intake, roadmap priorities and supported Advisor decisions. Local pull materializes canonical work. Executors change the project; verifiers evaluate evidence; the ledger remembers. Execution-gate decisions still need the supported local resolution path. A connector installed in ChatGPT or Claude is a separate setup step.

Private preview · client setup requiredTechnical 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 SEE
ILLUSTRATIVE LIFECYCLE
01Fix recorded
02New contradictory evidence
03Refinement proposed

The previous fix stays in history.

WHAT HAPPENS UNDERNEATHReveal ↓
  1. 01Fix
  2. 02Independent check
  3. 03New contradictory evidence
  4. 04Recurrence / reopening
  5. 05Durable lesson
  6. 06Governed next work

Canonical receipts preserve earlier fixes and new evidence. Strategic memory can carry lessons into future work. Framework retrospectives propose changes; they do not grant themselves authority to modify policy. A proposal, an adopted rule and a verified improvement are different facts.

Implemented · governed learningTechnical reference ↗
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.

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 hood

Project predicates + assertScope

Read the implementation ↗
02

One execution seat

A second worker cannot simply take the same local seat.

Under the hood

Canonical lease and authority checks

Read the implementation ↗
03

Intent is not execution

“Received in cloud” still means the Mac may not have read it.

Under the hood

Intent receipt → subsequent work projection

Read the implementation ↗
04

Merged is not deployed

A merge receipt does not prove the release reached users.

Under the hood

Separate merge, deploy and verification receipts

Read the implementation ↗
05

The worker cannot certify done

An executor’s “finished” is not an independent verdict.

Under the hood

Verifier boundary and evidence requirements

Read the implementation ↗
06

Waiting is a real state

Missing evidence keeps work parked with a wake condition.

Under the hood

EVIDENCE_PENDING + evidence plan

Read the implementation ↗
07

A blocked item need not stop everything

Independent work can continue when the authority and selector permit it.

Under the hood

Checkpoint scope, dependencies and eligibility

Read the implementation ↗
08

Cloud guides. Local executes.

Your phone reads state; your machine operates the repository.

Under the hood

Publisher + intent pull + canonical intake

Read the implementation ↗
09

Configured is not live

A configured publisher is not proof of a fresh observation.

Under the hood

Observation timestamps and stale state

Read the implementation ↗
10

Done must reconcile

External delivery and local lifecycle must agree.

Under the hood

Canonical closeout and reconciliation

Read the implementation ↗
THE COMPLETE LOOP

Three flows.
One project history.

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

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

Now see a real Factory.

Current observations, with their age and limits made visible.

Open Live Factories →Explore bounded experiments & deeper examples ↗