Organizing the work: structure and deliverables

Organization, teams and people

You come to this part to answer three questions: how my company is laid out in here, who works on what, and where the team's ground rules are agreed. It's three pages and one questionnaire.

Where these screens live

Organization, Users and Teams live in Settings, the sidebar entry right below the work sections. It opens a page with one row for each of them, plus Grouping, Billing and My Profile. The first entry in the bar is always Orion, right below Waiting on you — with an orange background while you are on another screen. Then comes Y Managers, which opens the team-management home, with the work sections indented right below it: Dashboard, Deliverables, Team Plans, Work Plans and Reports — plus Course, which only appears if your organization has an active course. At the end of the list sit the Manual (which opens at the chapter matching the screen you are on) and the Guided tour.

The Users row only shows up for people whose org role is Admin or HR. Anyone else never sees the people registry — not even the row in Settings.

Two other entries also depend on the role. Billing only shows up for the Admin — and, inside it, the billing actions belong to whoever was designated billing manager. Reports shows up for the Admin and for anyone who is a manager or assistant of some team, because reports carry per-person assessments: anyone who is neither gets a refusal from the server even if they type the address directly. The full map of who sees each page is in the roles and permissions chapter.

No subscription: what stays open and what gets a 🔒

In Y Managers, creating, signing and generating require a subscription, on a plan that includes the team dashboard — Orion Light (outside Brazil, paid by card), the free Orion BYOK and, in Brazil, Orion MEI and MEI+ don't include it. That applies after the organization's Y Managers free period — during it, everyone creates, signs and generates, whatever their plan —, and the Admin of an organization that pays for the team dashboard gets through, whatever their own plan. Someone without a subscription, or on a plan without the dashboard, keeps everything that already exists open to read, edit, delete and log progress. Who counts as having no subscription — for example, someone without any plan in an organization that pays — and what else changes are in No subscription.

Locked with a 🔒

creating (a deliverable, a task, a deliverables plan, a work plan, a decision — including correcting one —, a team, a grouping, an attachment on a deliverable, a copy of a deliverable or of a plan); signing (the plans, a deliverable's Review requested or Approved tag, the sign-off link, the renewal of an AI worker's plan); and generating (reports, the Situation and the AI suggestions — these use the organization's AI allowance, so they also require the organization to have a subscription). The button doesn't disappear: it shows with a 🔒, and the click only states the reason, with the shortcut to fix it.

Still open

inviting, importing and restoring people (Admin); adding and removing deliverables from a plan; requesting an adjustment; closing a deliverables plan; marking the tasks of a work plan, including approving a proposed allocation; filling in "What was done"; requesting a review of your own assessment; and the decision of whoever receives a deliverable's sign-off link.

The strip at the top. On the Y Managers pages, a strip says it once — "🔒 In Y Managers you can read, edit and log progress" —, with the reason and the way back: Subscribe, for the Admin (it leads to the Billing page); asking an Admin, for everyone else; See the plans, for someone on a plan without the dashboard. Through Orion — on WhatsApp, on Telegram, in the app or on voice — the same holds: it doesn't create, sign or generate, it states the reason and the way back, and it doesn't try again.

The Organization page

This is where your company's identity lives. The page shows for Admin, HR and Audit; a regular member doesn't see it in the menu. Only the Admin edits — HR and Audit see it read-only. The only exception is the assessment star-scale card (see Cycles, feedback and review requests), which HR also edits.

Identity

official name, brand name and logo.

Location & tax

address, country and the tax document in the country's format (CNPJ in Brazil, EIN in the US, RFC in Mexico and so on). The currency is neither chosen nor guessed from the country's name: it is the billing currency — Reais in Brazil, US dollars in every other country — and the page only shows it. Changing the country here follows the same rule as the Billing page: it changes the currency only when the change moves the organization to the other billing account (from Brazil to another country, or from another country to Brazil), and, if a payment page is still open on the old account, the change may be refused for a few minutes. After the first purchase — by card or by Pix — the account no longer changes: the list shows only the countries on the account's side, and a country on the other side is refused, with the reason, and nothing is saved. The billing country is corrected on the Billing page.

Contact

email, phone, website and LinkedIn.

Profile

company size, the organization's language (the language the system writes in for what it produces for the company — reports and generated text; your screen's language is a different setting, and it lives in My Profile), Consulting mode (turn it on for service firms that bill client work) and Team-level privacy.

People & ownership

the primary contact — the organization's representative for billing and legal notices, chosen from among the Admins — and the list of Admins. The roles themselves are set on each person's profile, not here.

Dashboard, cost and average rating access

a table of checkboxes where the Admin chooses who opens the Dashboard and, among them, who sees cost — by organization profile (Admin, HR, Audit, User) and by team role (manager, assistant, member, observer). One checked profile or role is enough to grant access, and the Admin is always checked. The default is the usual one: everyone sees the dashboard, and cost stays with the Admin and the managers. The third column, Sees average rating, chooses who sees the average cycle rating on the deliverable page and the deliverables plan; it does not depend on the dashboard. A checked profile sees it for every deliverable; a checked team role sees it for the deliverables of the person's own teams and those with no team. By default: the Admin, the manager and the assistant. Back to default undoes the choice.

Billing & subscription

plan and status, managed by the billing area.

The switch that changes day-to-day life the most is Team-level privacy. Off (the default), deliverables and deliverables plans are visible to the whole organization. On, a regular member only sees the deliverables and the deliverables plans of the teams they belong to. Admin, HR and Audit keep seeing everything in both cases.

Work plans follow a different rule, independent of this switch: a regular member always sees only their own plan, plus the plans of the teams they manage, assist or observe.

Teams

The Teams page has two panes: on the left the organization's hierarchy (with search and branches you can collapse), on the right the selected team — settings, members and its work agreement.

Creating a team is an Admin act: anyone who isn't an Admin doesn't see the ＋ New button at the top of the hierarchy, and the server refuses again, as a safeguard. The form asks for two fields: the name and the parent team (or "top level", if there isn't one). Nothing else. The team is born active — activating and deactivating comes later, in the settings of the team once it's selected.

The creation form doesn't ask who the manager is. The manager is designated right after, by adding the person to the team with the manager role. And the member picker only offers people who already exist in the organization: bringing someone in from outside is an Admin act, on the Users page.

There are four team roles — manager, assistant, member and the read-only observer role. The observer role is assigned from the team card, here on the Teams page. Each person has one role per team: picking one clears the previous one automatically.

Use the parent team to group by department ("Marketing", "IT"): the hierarchy feeds the dashboard filters and, as you'll see in Team deliverables plans, a child team inherits the deliverables plan of a team above it.

The guardrails around the structure

Some actions are refused on purpose, so you don't lose history without noticing.

Deleting a team

is an Admin act, and it's only possible if it has no sub-teams, no members and is nobody's home team. The screen disables the button and tells you what to move first; the server refuses again, as a safeguard. Work history is preserved.

Changing the parent team

Admin only. And the system refuses any change that would create a loop in the hierarchy (a team becoming its own ancestor).

The last Admin is protected

you can't demote, deactivate or remove the organization's only Admin. Promote someone else to Admin first.

Removing a member from the team takes away the role, not the person: they stay in the organization, and the work they did stays attributed to them.

On the team card you also see its AI workers. They don't show up through member association — they show up through the work plan, which is what actually ties a worker to this team and to its deliverables. In the AI workers block there is an Allocate AI worker button — it doesn't create a member link: it opens work plan creation directly, which is what ties the worker to the team. The button is disabled when every worker in the organization already has a plan on this team. The AI team has a chapter of its own.

Users: one person or a whole list

The Users page is the people registry, restricted to Admin and HR. The invitation is always by email — there is no invite code anywhere in the product.

When you add someone, you can pick the org role, the home team and the role within it all at once. An invitation email goes out immediately, and the person only joins the organization after accepting — until then they show as Invitation pending, and you can already prepare their record. If they decline, they leave the list and go to the removed users. Each address receives at most one invitation email a day, from any organization: if it already got one today (for example, when you remove and restore the person on the same day), the invitation is still created, but the email doesn't go out again — the screen tells you, and the person sees the invitation when they sign in to the platform with that email.

For whole teams, switch to the Multiple (paste list) tab and paste the lines. The format accepts two forms:

• just the email, one per line; or
• CSV: email, First, Last, OrgRole, Team, TeamRole.

Empty fields use the defaults you set just above the box, and the team is matched by name. The limit is 200 lines per batch. The list goes to the server in parts of 50; if a part fails, its lines show as "not sent" and the others go through normally — send just the missing ones again. On submit, you get the result line by line — invited, added, reactivated, without the invitation email for now, over today's limit, already members, duplicates, invalid, errors — instead of a generic "done".

Daily invitation limit. Each organization can send up to 50 invitations a day without a paid plan (during the trial or without a subscription) and up to 300 with a subscription — counting single invitations, batches and restored people who had never signed in. The top of + Add user shows how many are left today. Past the limit, the invitation isn't made (nothing is saved or sent) and, in a batch, the extra lines show as "over today's limit" — the earlier ones go through normally. The count restarts at midnight UTC. For a large rollout, the Orion team can raise the limit of an organization with a subscription.

One important note about departures: removing a user deactivates them. They lose access immediately, but their contributions (work plans, activities, assessments) stay attributed to them, so the organization's records stay true — and you can restore them. This is not data erasure: the "Delete permanently" option exists and is only unlocked for people with no work-plan history. Deletion/anonymization requests (LGPD in Brazil, GDPR in the European Union) are handled as a separate, explicit action.

The work agreement: the house rules, in questionnaire form

There is no free-text field for "team rules". What exists is the work agreement: a structured questionnaire of 13 questions, organized into four blocks:

Work Style & Location

primary mode of work and the policy for in-office days (with a weekday picker when the days are fixed).

Synchronous & Asynchronous Work

primary rhythm, recurring synchronous events, minimum notice for booking a meeting and the core availability window (with start and end times when it is fixed).

Communication Protocols

chat platform, channels and their purpose, expected response time for non-urgent messages, how to communicate urgency and after-hours boundaries.

Meeting Culture

the expectation about cameras and the minimum preparation for a meeting.

Each question has ready-made options and an open field, in case your answer isn't on the list.

The work agreement cascades down: organization → team → person. The answer that counts is the one from the most specific level that answered; a level left blank inherits the one above, and the editor shows in gray what you would inherit if you don't answer. That way the company sets the general rule once, the team adjusts what is different for it, and the person only records the real exception.

Each person sees their consolidated work agreement — the three layers already resolved — in My Profile, read-only.

And this is where it stops being paperwork: when a work plan is signed, the three layers of the work agreement in effect are frozen inside the plan. If the organization changes the policy later, what was agreed in that plan doesn't change along with it. You read the frozen text in the footer of the work plan itself.

Deliverables

The deliverable is the unit that makes work show up. Without it, the team has tasks; with it, the team has a result — and Orion has something to track, to chase and to narrate for you.

What a deliverable is

A deliverable is the final product or service that results from your team's work. It makes the value generated for the recipient visible and shows real progress toward objectives. When deliverables are clear, everyone understands exactly what has to exist at the end — which increases coordination, communication and motivation.

Examples: "Customer satisfaction survey conducted" (service), "App prototype created" (product).

Tasks and activities are the actions needed to produce the deliverable. The deliverable is the result of those actions. If you can cross an item off the list and nobody on the outside notices a difference, it's probably a task, not a deliverable.

Why insist on this: deliverables remove ambiguity about what is expected (focus), give you a number to track (measurability) and connect the day's work to the tactical and strategic plan (connection).

Projects and processes

A project ends. A process repeats. The platform handles both, and the difference is in the deliverable's status, not in the target type.

There is no "binary" target type. The list of target types comes from the types already used on your organization's deliverables. Until there are any, the platform offers %, unit and $ as a starting point.

Every deliverable marked Recurring is born with a cycle clock on, monthly by default. You change the length on the "Cycle clock" card (weekly, biweekly, monthly, quarterly, semiannual, annual or custom). Within the cycle, each process step is worth a slice sized by its weight; at the end of the cycle the real percentage is registered in the history and the steps reset for the next lap. That's why a process's progress doesn't leak from one month into the next. An older process with no clock that is part of an AI worker's work plan is set to monthly by the AI manager — whoever manages the team is notified and gets a link to undo it in one tap.

Creating a deliverable

Go to Deliverables → ＋ Create deliverable. Only two fields are required:

Deliverable title

write the result, not the activity — "PRD — Backlog features moved to development" works better than "do the PRD".

Owning team

the team that manages this deliverable. Choose carefully — it is immutable in ordinary editing.

The start date and the end date are required at creation — on the screen, in chat, by voice, and for anything Orion creates on its own. A deliverable with no deadline can't be planned: it stays out of the risk block, never shows up in bottlenecks, and sits at Not started even when the work is finished. The only exception is a Recurring deliverable, a continuous process that carries no dates at all — for it, both fields disappear from the form. If the deadline hasn't been decided yet, Orion asks instead of inventing one. The remaining fields are optional at creation and editable later, on the deliverable's page: status, recipient, type, category, grouping, target type and planned target. Grouping connects the deliverable to the strategic-plan hierarchy (objectives, initiatives, key results) that Admins maintain on the Grouping page. Each group can have an owner, an active person of the organization: the Admin chooses on the page, and recording the annual planning sets the owner of each objective and initiative.

You can do it through chat too: "create the deliverable 'Customer onboarding revised'". When you don't say the team, Orion uses your home team.

Creating and editing deliverables belongs to the manager or assistant of the owning team (or of the team above it), and to the Admin. Creating requires a subscription (see No subscription, at the start of this chapter); editing doesn't. A regular member opens the deliverable read-only, with the notice on screen — their contribution shows through task progress.

What locks, and when

Four fields make up the planned baseline: planned start date, planned end date, target type and planned target. They are not fixed from creation — you can adjust them while planning is still open.

What locks them is the arrival of the planned start date. From that date on, those four fields are frozen and the system refuses the edit, showing the notice "🔒 Planned baseline is locked (start date has passed)". From there on you use the parallel fields — updated start date, updated end date and updated target — and it is exactly that difference between planned and updated that shows how much the plan slipped.

The owning team is immutable in ordinary editing. Since July 27, 2026, however, an Admin can reassign the deliverable to another team through a dedicated action — it is no longer a "never".

Deleting a deliverable is refused in four situations, and the message says which one — and what to do:

• some task already has progress — reset the tasks' progress first;
• it belongs to a deliverables plan — if the plan is open, take it out of the plan first (🗑 on its row, on the plan's page — on a draft, removing is up to the manager or the assistant of the plan's team (or of a team above it), or an Admin; on a signed plan, only the manager or an Admin). If the plan has already ended, you can't: the list of an ended plan is a record and doesn't change;
• it is in a work plan — if the work plan is still being drafted, take it out of it first. If it already has a signature, the deliverable only leaves through the plan itself: with one signature, by requesting an adjustment; with both, through the Editing flow (see Work plans). From a finalized work plan it no longer leaves;
• it is a program template — it is copied into every new cohort; an Admin needs to detach it from the program first.

When the deliverable is part of a record (an ended or finalized plan) and is no longer going to happen, the way out is to set its status to Cancelled: it leaves the open work without erasing the history. There is also Create a copy, which is the normal way to repeat a similar deliverable in the following period: it asks for the start and end dates of the new period and carries the task list, without the progress.

Progress, status and what Orion does with it

The deliverable's progress is computed, never typed: it is the average of the tasks' progress, weighted by each one's weight. A task with no weight set counts as weight 1; a task with weight 0 is left out of the calculation on purpose.

Who can touch a task's progress: the Admin, the manager or assistant of the deliverable's team (or of the team above), whoever is flagged as a contributor on the task, and whoever selected that task in their own work plan. The task's planning fields — due date, planned start and predecessor — belong to the team lead.

The status also moves on its own, from the progress and the dates — in that order. *Progress at 100% closes the deliverable as Completed right away, even with the deadline still ahead: the deadline tells you whether the work landed on time, not whether it is finished. Below 100%, the dates rule: before the start it is Not started; between start and end it is In progress; if you pushed the end date out, it shows as Overdue between the planned date and the new one; past the end without reaching 100%, it becomes Not completed. The states you set by hand — Recurring, On hold, Cancelled, Completed, Not completed — the system respects and does not overwrite. With the deliverable Completed, Not completed or Cancelled — by you or by the system itself, with progress at 100% or the deadline passed —, its tasks are frozen. To reopen it, change the status. If the deadline has already passed, also replan the end date: otherwise, within half an hour the system closes it again as Not completed*.

Two things happen on top of this without you asking. The morning brief brings the deliverables at risk, with the reason computed: deadline passed with work still pending, progress behind the pace expected for the slice of time already consumed, or progress stuck for several days. And, on the deliverable's page, the Situation button compiles into text what the work plans linked to it say — useful before a follow-up meeting (compiling uses AI, so it needs a subscription).

Projected cost and average rating

On the deliverable page, the Who has worked on this deliverable card adds up the hours and cost of the signed work plans and shows two more lines:

• Projected cost to completion (for those who see cost): the cost of the days already past in the signed plans, of the days still ahead in them and, if the deliverable stays open after the last plan, the same pace of the latest plans until the deadline. A completed, cancelled or recurring deliverable is not projected past the plans; with the deadline passed, the line says the projection stops at the signed plans.
• Average cycle rating (by default, for the Admin and for the manager or assistant of the deliverable's team; the organization chooses under Organization): the stars of the already-rated cycles of the plans that worked on the deliverable, weighted by each plan's effort on it. The automatic 3★ counts, and the line says how many there were.

The projected cost follows the cost column of the same choice. AI worker plans stay out of both. The How it's calculated button, under the lines (and under the deliverables plan table), explains each calculation on the screen itself. Orion does not read these two numbers in the conversation: to see them, open the deliverable page.

Sign-off: who says the deliverable is done

Every deliverable has a ✅ Deliverable sign-off card. It's where you record who approves that result: someone inside, picked from a search among the registered people, or someone outside — by email or by WhatsApp, with name and contact typed in by hand.

With the approver set, the Generate sign-off link button creates an address of that deliverable's own, which opens a decision page with no login: whoever receives it sees the title, the team, the progress and the tasks, and decides between approve or send back for changes. Sending it back requires a comment — without one the system refuses the decision. When the approver is someone inside, they get the link by email right away; for someone outside, you send the link through whichever channel you prefer. Generating the link belongs to the manager or assistant of the deliverable's team (or of the team above), or to the Admin, and requires a subscription: without one, the button shows with a 🔒. Generating the link also puts the deliverable into review and sets a 30-day review deadline, if it didn't have one yet. Like every page that opens without signing in, the sign-off page takes a limited number of decisions per hour from the same connection — far above what one person uses (see security and privacy).

The decision page speaks Portuguese, English and Spanish. It first tries the approver's own language, when they are someone inside; then the language of the browser that opened the link — usually the right signal when the approver is an outside client. At the top of the page there is an EN/PT/ES switch, in case the guess is wrong. The e-mail that notifies an internal approver goes out in their language.

The decision comes back written on the deliverable's page: approved or sent back, by whom, when and with the comment. Sending it back doesn't create tasks on its own — you read the notes and define the review's tasks.

With no response by the deadline, the deliverable is approved by lapse — and it stays marked with that word, so nobody confuses it with a real sign-off. This applies to a deliverable that has an approver recorded and a review deadline set, which is what the link establishes. The default deadline is 30 days and you edit it in the review's deadline field — but note that the link you sent is valid for 30 days: if you stretch the deadline beyond that, the address already delivered stops opening and you have to generate another one.

Without a subscription, there is no approval by lapse. While the organization has no subscription, that deadline is paused, and the review block on the deliverable says so. When it subscribes again, the open review's deadline becomes 30 days from that day — or the date already set, if that is later. If the link you sent expired during the pause, generate another one on the deliverable.

The Approval field, in the details block, is the same control from the inside: No tag, Review requested or Approved. Without a subscription, Review requested and Approved show with a 🔒 (asking for sign-off and approving count as signing); No tag and Discard review still work. While a review is under way, the deliverable's status is read from it: In review while the review tasks haven't reached 100%, Reviewed when they do (work done, waiting for approval) and Approved after the sign-off. During that period the normal status is locked — the review is what rules. The review's tasks have a bar of their own and don't count toward the deliverable's progress: the original work isn't diluted by the rework. Approving doesn't erase the review — it stays as a record, read-only. And an approved deliverable is frozen as a whole: the original tasks and the review tasks no longer change, and no new task can be added. To reopen it, set the field back to Review requested. To undo all of this there is Discard review, the first option in that same Approval field once there is a review: it asks for confirmation, removes the review's tasks and the justification and returns the deliverable to its normal status.

On the deliverable's page you can also attach material under Associated with this deliverable: a link (Drive, Workspace, URL) or an uploaded file — PDF or text (txt, md, csv), up to 25 MB. Attaching to a deliverable counts as creating, so it requires a subscription; loose material, in Knowledge, still works. The text of txt, md and csv files is read when you send them, and it's what Orion uses when you ask about that deliverable's content. A PDF is kept for download, but its text is not read yet: for Orion to use it, open the item in Knowledge, tap ✎ Edit and paste the text into it. Someone with the Audit role only reads the deliverable's material: they don't attach or edit — in Knowledge, they only save their own 🔒 Personal notes.

Team deliverables plans

The deliverables plan is the portfolio the team commits to working on over a period. It exists for a practical reason: it is its signature that releases the building of the individual work plans. With no signed deliverables plan, the team has nothing to lean on — and the system refuses.

What it's for

The deliverables plan defines the team's priorities during its effective period and serves as the reference for the members' work plans. It ensures alignment (daily work pulls the agreed results) and anticipates dependencies and allocation before the period starts.

It belongs to one team. And it holds for the teams below it: a sub-team with no plan of its own leans on the plan of an ancestor team.

Step 1 — Create

Go to Team Plans → Create deliverables plan. There are four fields: title, team, start date and end date. The plan is born as a Draft.

The Team Plans list opens showing the plans in progress and the drafts — everything that has not closed yet, Planned included. That way the plan you have just created does not disappear from view while it waits for a signature. The status selector at the top isolates one status, or shows them all. In the conversation with Orion the count is the usual one: he answers for the plans in progress and says how many were left out.

One precaution that saves rework: check all four before creating. Today there is no screen to edit or to delete a deliverables plan once it's created — the title, the team and the period stay as they were saved. What changes afterwards is the content (deliverables come in and out — see who can in Step 2) and the status (through the signature, the calendar or the early close).

Through chat: "create a deliverables plan for the Product team, from September 1 to December 31, called 'Q4 2026 — Product'".

Step 2 — Insert deliverables

On the plan's page, use ＋ Insert deliverables. Search by title, check the ones the team will work on in the period and confirm with Add (n).

To take a deliverable out of the plan, use the 🗑 (Remove from plan) on its row. Removing is a double confirmation: the 🗑 only opens the confirmation, which says what will happen — the deliverable leaves the plan's list, but it still exists, with its tasks and progress, and can come back to the plan later through ＋ Insert deliverables; on a plan that has already been signed, the removal is recorded in the plan's decisions —, and the Yes, remove from plan button is only released after you check I understand the deliverable leaves this plan. Each deliverable opens its own confirmation. Taking it out of the plan doesn't delete the deliverable.

One exception about coming back: ＋ Insert deliverables only lists open deliverables. A deliverable that is already Completed, Cancelled or Not completed doesn't show up there — to bring it back to the plan, ask Orion in the chat. The confirmation already says so when that's the case.

A deliverable taken out of a signed plan no longer counts for work plans. A deliverable only counts for work plans while it is on the list of a signed, active deliverables plan. Once it is taken out of the signed plan, unless it is in another plan like that, it can no longer go into a work plan (not through ＋ Add deliverable, ⧉ Copy or ✨ Generate work plans for the team), and a work plan that already has it and is not yet signed by both parties can only be signed once it is back in a signed plan or taken out of that work plan — the refused signature says which plan it left and when. A work plan already signed by both parties stays as it is, with the deliverable, its cycles and its reports. The 🗑 confirmation says so on a signed plan. Taking it out of a draft changes none of this: a draft's deliverables didn't count for work plans yet.

Who adds and who removes

• On a draft (before the signature), adding and removing deliverables — the same rule for both — is for the manager or the assistant of the plan's team (or of a team above it) and the Admin — the assistant helps build the plan.
• A manager or assistant of another team — a sibling, or one below the plan's — doesn't touch this plan.

The screen only shows ＋ Insert deliverables and the 🗑 to whoever can use them, and the server refuses again, as a safeguard.

After the signature (Planned or In progress), the portfolio has become a commitment: adding and removing deliverables is then up to the manager only (or the Admin), and the assistant sees the 🔒 notice instead of the buttons. Every change is recorded in the plan's Decisions & lessons: what came in or went out, who changed it and when — with the reason, when you tell it in the chat.

After it ends (by the calendar or early), the plan's deliverables no longer change: nobody adds or removes — not the Admin, not on the screen, not through the chat. A deliverable from it that will still be worked on goes into the new period's plan.

A plan that reaches its end date without being signed isn't closed: it stays a Draft, and its deliverables come in and out by the draft's rules (see Step 3).

Through chat: "take the deliverable 'Revised onboarding' out of the Product Q4 plan". Orion follows the same rules and checks before asking: if the deliverable wasn't in the plan, he says nothing was removed; if the person asking can't change this plan (on a signed plan, only the manager does), or the plan has ended, he says so. When it can be removed, he says which deliverable leaves which plan — on a signed plan, also what changes for work plans — and only removes it after your yes.

The plan's table shows, for each deliverable: progress, status, target, end date and who has worked on it — with the count of work plans per person. At the top, the plan's deliverables completion bar. Those who see cost also see, under each deliverable's hours, the projected cost to completion; the Admin and the manager or assistant of the deliverable's team see, under who has worked, the average rating of the cycles (see Projected cost and average rating, under Deliverables).

Step 3 — Sign

Once the portfolio is assembled, the ✍ Sign plan (manager) button appears. Signing is an act of the manager of the plan's team (or of a team above it) or of an Admin — a manager of another team (a sibling, or one below the plan's) doesn't sign, and assistants assemble the plan, but don't sign for it. Without a subscription, the button shows with a 🔒.

A draft doesn't change status on its own, not even when its end date passes: it stays a Draft and the manager can still sign it. Signed after the end of its period, it goes to In progress, and the clock closes it on the next round, because the period is already over.

The signature picks between two states, depending on the date:

Planned

the period hasn't started yet. It isn't a draft — it's a commitment already reviewed, waiting for the date. You can already build work plans on top of it; that is exactly why this state exists.

In progress

the period has already started (or starts today).

From there on the clock takes care of the rest. Every 30 minutes the system promotes Planned → In progress on the start date, and In progress → Finished when the period ends. On closing, whoever manages the team gets an invitation to record the period's lessons — a short retrospective that becomes precedent for the next cycle.

The on-screen notice after signing says the essential: "✓ Signed — work plans can now be built against this plan." This is also where the ✨ Generate work plans for the team shortcut sits, which splits the plan's deliverables across the active members for you to review before anything is created (see Work plans). It shows only to whoever leads the plan: the manager or the assistant of the plan's team (or of a team above it) and the Admin. Everyone else sees the notice, but not the shortcut. When the plan ends (by the calendar or early), the notice and the shortcut leave the page: a closed plan no longer generates work plans, neither on the screen nor through the chat. The deliverables that will still be worked on go into the new period's deliverables plan, and the work plans come from it.

Orion proposes the breakdown into tasks

A deliverable that went into a signed plan and has no live task at all is scope with no "how": nobody knows what to do tomorrow morning. Since August 14, 2026, when that happens, the AI manager writes a draft of 2 to 5 tasks for each deliverable in that situation and sends it out for a decision. (In an organization without a subscription, the AI manager is paused and writes no draft.)

The draft arrives spelled out in full — "📝 Draft from the AI manager — awaiting YOUR decision" — and it shows up for every manager of that team, in the Waiting on you box and in Orion's channel: whoever gets there first decides. You approve, adjust or refuse, and only approval creates the tasks — so approving requires a subscription: without one, the draft shows with a 🔒 in Waiting on you, approval through the conversation is refused and it keeps waiting; refusing still works. If the team has turned on the "Break down work for me" autonomy (see Work plans), he starts creating them on the date, always giving notice the day before of which deliverables are coming in and how many tasks are born.

Closing early

Sometimes the period changes shape halfway through: the team is reassigned, the priority drops, the project ends sooner. The Close early button exists for that, and it sits at the same level as the signature — whoever opened the commitment is the one who closes it (the manager of the plan's team or of a team above it, or the Admin).

Before anything else, the system runs a preflight: it computes and shows the real consequences, not a generic warning.

• how many days before the planned end you are closing;
• which deliverables stay live and end up with no deliverables plan — with each one's progress;
• how many work plans keep running (cycles and assessments do not stop);
• which AI workers are blocked from renewing a plan on those deliverables until they belong to a new signed plan;
• which teams end up with no source plan, which blocks the creation of new work plans — for people too, not just for the AI.

After that, closing requires a justification of at least 15 characters. It isn't bureaucracy: it is recorded as a decision on the plan and it's what the next period will read. Only then is the confirmation accepted, and the action is irreversible through the interface.

Two things that do not happen, because that's the real question of whoever clicks: the deliverables and the work plans are not closed along with it. They stay live, with their cycles and their assessments. Open deliverables can go into another plan later — and that doesn't have to be decided now.

The same contract holds through chat. If you say "close the Product team's deliverables plan", Orion first gives you back the list of consequences computed by the server, word for word, asks for the reason in your own words and only closes after your explicit yes. It never invents the justification.

Once closed this way, the plan shows the Closed early badge, with the date, who closed it and the justification visible on the page itself.

What you still can't do

Worth saying plainly, so you can plan around it: there is no editing of the plan after it's created (title, team, period), there is no deleting a plan, and the signature is not reversible — the way to undo a signed commitment is the early close, with a recorded justification.

The annual planning

The annual planning has its own chapter: The annual planning. It covers who starts and who leads, preparing, the interviews, the synthesis, deciding each card, the breakdown into the plan tree, the plan's deliverables, each team's time, and the approval and the plenary.