Documentation · illustrative operating examples
The kernel manages persistent work, evidence, authority and independent verification. Each domain supplies its own work model, tools and definition of done.
Watch a day in the loopOperating model and illustrative examples. Check current availability.
Illustrative product operating model
A review is pending. An old bug needs a fix. A new release is about to surprise you. Follow the work through one illustrative morning.
Explore the interactive eventsThe search fix needs an independent review. Orchestro saves its context, priority and evidence, then frees the active slot. The next useful job can start immediately.
Search fix: waiting for review. Checkout bug: now active.
Different error messages point to the same checkout timeout. Orchestro proves which reports share the same mechanism, then coordinates one fix, independent review and release. Similarity alone is not enough.
One underlying cause gets one investigation and one repair.
After the release, monitoring spots a burst of server errors. A new regression takes priority over routine backlog work. Orchestro investigates the cause and prepares a repair within the project’s permissions.
Urgent recovery moves first. The other work keeps its place.
The regression fix is released, but needs 60 minutes of real traffic before it can be called resolved. Orchestro parks that verification and resumes the backlog. A release alone is never proof of recovery.
Waiting for traffic frees the next job to run.
The search review arrives. Its saved work becomes actionable again: checks pass, then merge, release and verification. Separately, the regression’s traffic window can now be evaluated against its recovery criteria.
An event wakes the right job. It never had to hold up the morning.
An old error was classified as expected behavior. Twelve new occurrences look different. The Critic challenges that conclusion, reopens the investigation and checks whether this is the same cause or something new.
A past decision stays open to new evidence.
A test has a baseline, at least 50 samples and a seven-day deadline. In this example, failure below 1% means adopt; above 3% means reject. The middle band or too little evidence means inconclusive, with at most one bounded follow-up.
When the follow-up ends, decide or record insufficient evidence. Clean up temporary instrumentation.
The checkout works again. The urgent regression has passed its traffic checks. The reviewed search fix has its own release evidence. Open questions remain visible, and Orchestro selects the next actionable job.
The goal is to keep your product healthy, continuously.
Illustrative scenario. Scroll to follow the work.
Illustrative campaign operating model
A creative is waiting for approval. A landing page needs work. Results need time to mature. The same loop, with different tools, evidence and limits. Design-partner example.
Explore the interactive eventsA new creative needs your approval. Its context stays saved while the team investigates a landing-page problem within the already approved scope.
Waiting for a human decision never grants permission to publish.
Several ads show the same drop after a click. The evidence points to a broken mobile form on their shared landing page. One verified repair can address the shared cause.
Investigate the common cause before rewriting every ad.
A broken campaign link appears while ads are spending. The loop prioritizes it, pausing the affected delivery only where that permission was granted. New spending still needs your decision.
Act within agreed budget and publishing limits.
The repaired form passes a separate functional check. Measuring conversion needs a mature cohort and the agreed attribution window. That measurement waits while another approved task moves forward.
A working form and better conversion are separate conclusions.
Your creative approval arrives. The saved work resumes with a quality check, publication within the approved budget and a separate delivery check.
The approval wakes that campaign, with its original limits intact.
Yesterday’s best creative starts attracting a different audience. The Critic checks cohort, spend, tracking and attribution before deciding whether the old conclusion still holds.
Observed improvement is not automatically a causal lift.
The experiment reaches its declared deadline. Evaluate the target metric, sample requirement and guardrails. Adopt, reject or record inconclusive, with at most one bounded follow-up. More time never appears by default.
No endless test, no silent spend increase, no invented winner.
The form works. The creative is approved and live. Budget decisions have an owner. Conversion remains a measured question until comparable, mature evidence supports a conclusion.
Every action has a reason. Every result has evidence.
Illustrative scenario. Scroll to follow the work.
A failed release stays failed, even when code is merged. Use a bounded retry, an authorized rollback or a technical repair. If a new release harms production, rollback is a first-class recovery option. Then select the next useful job.
If the work history, repository and production disagree, stop changes to that affected item. Record the authority conflict, repair the evidence and keep other independent work moving.
Investigate whether the new failure shares the original cause. Reopen the same causal boundary when it does; create a new one when it does not. Similar symptoms alone are not proof of a shared cause.
An inconclusive test can have at most one bounded follow-up in these examples. At the limit, record not measurable or insufficient evidence, or request an explicit owner decision about further investment. Remove temporary instrumentation.
Monitoring spots failed checkouts. The mission stays active even when nobody is writing a prompt.
Signal saved with source and affected behavior.
Monitoring spots failed checkouts. The mission stays active even when nobody is writing a prompt.
The investigator reproduces the timeout and links it to an exhausted connection pool. Similar-looking reports still need evidence.
Checkout is actionable. The search fix keeps its priority and history while waiting for an independent review.
It plans a focused repair and a regression test. The kernel checks the affected service, allowed changes and run budget.
The worker prepares the fix. In this scenario, green review gates permit a release. Deployment is recorded; the job remains open.
The verifier checks the released checkout against the original failure and the agreed observation window. The worker cannot certify itself.
The repair history records the retry failure and its regression check. A project lesson is not automatically a universal kernel rule.
A slow order confirmation becomes new work. The repaired checkout keeps its evidence; the search review still has its place.
Evidence mining finds a lesson in project notes. The mission is to run a publication, not just generate one article.
The domain checks novelty, source quality and relevance. A promising idea becomes work with explicit editorial acceptance criteria.
This article has enough source material to proceed. A previous article waits for its measurement window without blocking new work.
The agent chooses the outline, examples and internal links. The domain adds voice, factual and adversarial review requirements.
The draft passes its editorial gates. The publishing adapter acts within existing authorization. A publication receipt is still not proof of a good outcome.
A separate check reads the published page and verifies the text, sources and links. Traffic and commercial impact remain a later question.
Record the editorial lesson now. Evaluate audience response only when a defined measurement window supplies enough evidence.
An unanswered reader question becomes research work. The article keeps its sources, reviews and publication evidence in the same history.
A guided model of the two domains, not a live dashboard. No code is deployed, no content is published. Switch domains at any stage to compare the same kernel.
What is Orchestro?
A runtime for autonomous operations: persistent work, evidence and memory let agents maintain a mission across tasks, sessions and releases.
Durable backlog and memory. Work lifecycle and selection. Evidence, execution and independent verification. Governor, authority boundaries and learning records.
Shared across domainsWhat a job is. What evidence matters. Which tools can act. The policy, verification rules and conditions that make a job complete.
Reliability: a verified repair.The architectural direction separates a cloud control plane for domains, work, intent, health and receipts from execution on a local or cloud host. Private cloud capabilities exist; a complete hosted, self-service SaaS is still in development.
Cloud architecture and current limitsThe building blocks
The core keeps the rules. A project pack brings your goals, tools and checks. The agents do the work.
Each part adds a function. All share one history.
The core coordinates the loop: read evidence, choose permitted work, keep its history and require a check. The kernel is the central machinery inside that core.
So each new project inherits the rules instead of inventing another scheduler.
Select a checkout repair only when the evidence and permissions allow it.
Shared private kernel, reused by Reliability and the manually configured Content Factory pilot.
A pack defines the project’s sources, goals, tools, checks, release surfaces and permissions. The core reads this configuration; it does not guess how your business works.
So different projects can share a core without sharing credentials, budgets or authority.
Runtime errors, a repository, checkout tests and web or mobile release checks.
Configured per domain. Content has a real pilot; the campaign example here and a ready-made pack marketplace are not shipped integrations.
A supported agent receives a bounded task and the tools the project allows. Providers and subscriptions can change without becoming the owner of the work’s history.
So the system can use your tools while keeping scope, cost and permissions explicit.
Investigate the reproduced failure and propose a focused repair.
Depends on configured adapters, an available host and your agent quota.
The agent’s report is not the verdict. A separate review checks the exact revision; release verification checks what users actually receive. A required check must be controllable or allow the job to wait safely.
So a finished task cannot quietly turn into an unproven success claim.
The original checkout failure passes on the released version, with enough real traffic.
Checks and review authorities must be configured. A demo receipt is not live proof.
Sources and durable receipts record what happened. Ready work, waits and views are reconstructed from that canonical history, rather than the memory of one agent session.
So another agent or a restarted process does not have to invent the state again.
Keep the same cause, review, release evidence and traffic wait together.
Durable history is a foundation. ARVO’s demonstrated parking recovery informs Orchestro’s broader target.
The Governor handles operating limits and stalls. The Critic questions old conclusions. The Lab runs tests with an end date. Each adds a function to the same loop.
So learning and supervision improve the system without creating shadow backlogs.
Reopen an old classification when new errors contradict it; end an inconclusive test.
Roles in the operating model. Complete continuous learning and unattended recovery remain roadmap.
The core coordinates the loop: read evidence, choose permitted work, keep its history and require a check. The kernel is the central machinery inside that core. So each new project inherits the rules instead of inventing another scheduler.
Product: Select a checkout repair only when the evidence and permissions allow it.
Marketing: Apply the same work-and-evidence rules to a campaign, with the project’s own approvals.
Shared private kernel, reused by Reliability and the manually configured Content Factory pilot.
A pack defines the project’s sources, goals, tools, checks, release surfaces and permissions. The core reads this configuration; it does not guess how your business works. So different projects can share a core without sharing credentials, budgets or authority.
Product: Runtime errors, a repository, checkout tests and web or mobile release checks.
Marketing: Campaign signals, approved creative, spending limits and a mature measurement window.
Configured per domain. Content has a real pilot; the campaign example here and a ready-made pack marketplace are not shipped integrations.
A supported agent receives a bounded task and the tools the project allows. Providers and subscriptions can change without becoming the owner of the work’s history. So the system can use your tools while keeping scope, cost and permissions explicit.
Product: Investigate the reproduced failure and propose a focused repair.
Marketing: Prepare an approved creative variant or repair the landing page within scope.
Depends on configured adapters, an available host and your agent quota.
The agent’s report is not the verdict. A separate review checks the exact revision; release verification checks what users actually receive. A required check must be controllable or allow the job to wait safely. So a finished task cannot quietly turn into an unproven success claim.
Product: The original checkout failure passes on the released version, with enough real traffic.
Marketing: The approved creative is delivered and its destination works. Conversion improvement needs separate evidence.
Checks and review authorities must be configured. A demo receipt is not live proof.
Sources and durable receipts record what happened. Ready work, waits and views are reconstructed from that canonical history, rather than the memory of one agent session. So another agent or a restarted process does not have to invent the state again.
Product: Keep the same cause, review, release evidence and traffic wait together.
Marketing: Keep the approval, delivery receipt and measurement window tied to the same campaign.
Durable history is a foundation. ARVO’s demonstrated parking recovery informs Orchestro’s broader target.
The Governor handles operating limits and stalls. The Critic questions old conclusions. The Lab runs tests with an end date. Each adds a function to the same loop. So learning and supervision improve the system without creating shadow backlogs.
Product: Reopen an old classification when new errors contradict it; end an inconclusive test.
Marketing: Recheck yesterday’s winning creative against a changed audience; retire an expired experiment.
Roles in the operating model. Complete continuous learning and unattended recovery remain roadmap.
An explanation of the architecture, not an installation screen. How project connections work · Current availability
A waiting item leaves the active slot. An urgent regression changes the priority. The whole portfolio keeps moving.
Errors, feedback, QA and post-release monitoring supply the evidence.
Group reports by cause. Explain noise. Give unknowns a bounded evidence plan.
Select actionable work. A serious production regression takes priority.
Reproduce the failure and fix its cause within the project’s permissions.
A real finding needs reproduction, a fix and another review. No self-certification.
Record merge, deployment and distribution separately for each release channel.
Check the release immediately and over time. Recover or roll back within authority if it regresses.
Require released behavior and the agreed evidence window before declaring a cure.
Resume the next useful job. Retain evidence and watch for recurrence.
Review unavailable, traffic still maturing or a decision pending: save the work and its wake condition. Return it to selection when it becomes actionable.
The Critic can challenge a duplicate, an expected behavior classification or a claimed cure when new evidence contradicts it.
Why these rules exist: what running a Reliability Factory on ARVO taught us. The technical lifecycle below uses the product example.
First decide what the evidence means. Only actionable work enters the repair path; the other routes keep their context and conditions.
Keep the evidence. Do not invent a product fix.
Attach the signal to the canonical cause. If cured, check recurrence first.
Declare baseline, sample target, due date and success, failure or inconclusive criteria. Park until due.
An actionable cause can enter the repair loop within existing authority.
Get a direction decision where needed before starting implementation.
Respect spending, infrastructure and recovery limits.
Record a real permission decision. Keep independent work moving.
150 occurrences of one timeout + 30 platform-noise events + 15 occurrences of another regression + 5 unknowns become two identified causes, explained noise and five open questions. Keep every event linked to its evidence.
Use the observation windows configured for the project. A serious regression can interrupt ordinary work at any point; waiting for a sample frees the active slot.
Check release health
Evaluate early traffic
Check sustained behavior
Reconfirm the outcome
Each outcome returns to selection. A cure stays open to future evidence; the Critic can challenge any conclusion.
Inspect a checkout repair in Web, Chat + MCP or CLI. Follow its evidence through a technical wait, release and independent verification. All data is illustrative.
QA and user feedback point to the same checkout failure. Keep the reports together and investigate the cause.
What should we work on?
QA and user feedback point to the same checkout failure. Keep the reports together and investigate the cause.
One backlog item, with both reports attached.
| Work state | Ready to investigate |
|---|---|
| QA finding | Checkout cannot be tapped on mobile Safari. |
| User feedback | “I fill in my address, but I can’t pay.” |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- backlog list --pack packs/my-app
{
"items": [
{
"backlogItemId": "demo-checkout",
"title": "Fix mobile checkout",
"priority": "P1",
"status": "open"
}
]
}Work is within the project’s approved scope. Investigation can start.
The keyboard covers the checkout button. The coding agent adjusts the layout and adds a regression test.
What is the agent changing?
The keyboard covers the checkout button. The coding agent adjusts the layout and adds a regression test.
The repair is ready for review and checks.
| Work state | Repair in progress |
|---|---|
| Reproduction | Fails with the keyboard open in mobile Safari. |
| Change | Keep the payment button inside the visible area. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- stato --json --pack packs/my-app
{
"lavoro": {
"identity": "backlog:demo-checkout",
"titolo": "Fix mobile checkout",
"fase": "IN_REMEDIATION",
"inEsecuzione": true
}
}The coding agent has a bounded task, a reproducer and a success check.
Checks fail before release. The Governor parks this item and lets other authorized work continue.
Do I need to unblock anything?
Checks fail before release. The Governor parks this item and lets other authorized work continue.
Technical stall. Not escalated to the owner.
| Work state | Waiting for CI |
|---|---|
| This task | Waiting for green checks. No merge or release. |
| Other work | The settings copy task can continue. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- governor recap --hours 6 --pack packs/my-app
{
"recap": {
"windowHours": 6,
"decisions": 1,
"technicalWaitsParked": 1,
"ownerEscalations": 0
}
}Wait for green. Keep the release gate. Continue independent work.
CI passes. Within this example’s existing release permission, the reviewed change is merged and deployed.
Is the issue fixed yet?
CI passes. Within this example’s existing release permission, the reviewed change is merged and deployed.
Released. Still waiting for independent verification.
| Work state | Released · check pending |
|---|---|
| Checks | Regression tests and code review passed. |
| Delivery | The version containing the fix is deployed. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- diary --signal backlog:demo-checkout --pack packs/my-app
{
"signals": [
{
"signalIdentity": "backlog:demo-checkout",
"lifecycle": "WAITING_VERIFICATION",
"kinds": [
"remediation",
"merge",
"deploy"
]
}
]
}Release is already authorized for this example. New publishing authority would need you.
A separate check opens the released checkout on mobile Safari, brings up the keyboard and completes the payment flow.
What changed while I was away?
A separate check opens the released checkout on mobile Safari, brings up the keyboard and completes the payment flow.
1 issue shipped and verified. Evidence stays with the task.
| Work state | Verified |
|---|---|
| Independent check | Original mobile Safari reproduction now passes. |
| Result | Required checks for this example are complete. |
Illustrative canvas; rendering depends on your chat host.
$ npm run northstar -- diary --signal backlog:demo-checkout --pack packs/my-app
{
"signals": [
{
"signalIdentity": "backlog:demo-checkout",
"lifecycle": "CURED",
"kinds": [
"remediation",
"merge",
"deploy",
"verification"
]
}
]
}This work is complete. Select the next authorized task and retain the history.
Interactive product example. No live customer data. Availability
Four product-recovery examples. Choose an event to see how the operating model handles it. These controls only change the demonstration.
A failed release stays failed, even when code is merged. Use a bounded retry, an authorized rollback or a technical repair. If a new release harms production, rollback is a first-class recovery option. Then select the next useful job.
The affected release stays failed. Independent work can continue.
When the retry limit is exhausted, repair or escalate explicitly. A recovery action never certifies its own success.If the work history, repository and production disagree, stop changes to that affected item. Record the authority conflict, repair the evidence and keep other independent work moving.
Changes to this job are blocked until the sources agree. The rest of the portfolio remains available.
This example corrects a false release claim; it does not invent a deployment.Investigate whether the new failure shares the original cause. Reopen the same causal boundary when it does; create a new one when it does not. Similar symptoms alone are not proof of a shared cause.
The checkout was cured under P-B. A new packaging error now appears on the same route. A similar location alone does not identify its cause.
Investigate first. Keep the previous cure and the new evidence visible.
An inconclusive test can have at most one bounded follow-up in these examples. At the limit, record not measurable or insufficient evidence, or request an explicit owner decision about further investment. Remove temporary instrumentation.
Example reliability contract: baseline recorded on 2 October, at least 50 samples, decision by 9 October. Adopt below 1% failure; reject above 3%. The middle band stays inconclusive.
Choose the evidence and evaluate the contract. Elapsed time alone never proves success.
Bounded follow-ups used: 0 / 1. Changing the sample does not reset this limit.The coding agent’s report is not the final authority. Check the released system against the original failure and agreed acceptance criteria.
Merged is not deployed.Check the actual server, migration or edge-function release and the affected user path.
Built is not distributed.Record the app version, distribution channel and device evidence. A store submission is not a verified user result.
Recovery is not business impact.Measure conversion, cost or engagement with defined cohorts and mature data. Keep unproven outcomes explicit.
The selector can move “Repair a connection left open after a retry”. Waiting work keeps its context.
Checkout times out after a failed retry.
The reproducer finds a connection left open.
A successful retry must release the connection too.
No waiting job was discarded
Content examples draw on real editorial work and product-page audits, with names, artifacts and outcomes generalized. Playback compresses the sequence; it does not represent execution time. No command runs and nothing is published.
The selector can move “Explain why open work is not always ready work”. Waiting work keeps its context.
The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim.
The worker changes content/blog/ready-work.md. The scope stays attached to the work.
The draft says “our system” without naming the artifact that supports the claim.
Name the work ledger, link the source and keep the project-level limit.
The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check.
Reviewed paragraph, source links and canonical match.
Audience measurement waits for the declared 90-day window.
The selector can move “Correct an unsupported offline claim”. Waiting work keeps its context.
The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim.
The worker changes pages/mobile-companion.md. The scope stays attached to the work.
The proposed copy still promises offline behavior the inspected flow does not support.
State the connection requirement in the page and FAQ. Preserve its URL and title.
The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check.
Body, visible FAQ and structured answer agree; protected pages unchanged.
Record the baseline; evaluate traffic and CTA impact in a comparable window.
The selector can move “Repair a connection left open after a retry”. Waiting work keeps its context.
The worker inspects the source and records what it supports. Missing proof is work to do, not permission to invent a claim.
The worker changes src/checkout/retry.ts. The scope stays attached to the work.
The first patch handles success but leaves the failed retry path open.
Move cleanup to the shared exit path and add the failing retry to the regression test.
The configured adapter acts inside the existing authority. A release receipt records the change; the outcome still needs its own check.
The released retry passes the original reproduction and the declared recheck window.
Retain the technical verification; business impact remains unmeasured.
Implementation and pilot snapshot · 4 October 2026. Private access, with configuration and permissions defined per domain.
Your goals. Your permissions. Your evidence.