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

There is no "Settings" menu. The sidebar is a flat list of destinations, and each one is its own entry: Dashboard, Deliverables, Team Plans, Work Plans, Orion, Organization, Users, Teams, Grouping, Reports, Billing and My Profile — plus Course, which only appears if your organization has an active course. At the foot of it sit the Manual (which opens at the chapter matching the screen you are on) and the Guided tour.

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

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.

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 not chosen — it is set by the country.

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.

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 Combinado (working 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 the 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.

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. On submit, you get the result line by line — added, reactivated, already members, duplicates, invalid, errors — instead of a generic "done".

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/GDPR) are handled as a separate, explicit action.

The Combinado: the house rules, in questionnaire form

There is no free-text field for "team rules". What exists is the Combinado (working 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 Combinado 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 Combinado — 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 Combinado 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.

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.

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. 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 three situations, and the message says which one: when some task already has progress, when it belongs to a deliverables plan, or when it is in a work plan. Remove it from the plans (or reset the progress) first. There is also Create a copy, which is the normal way to repeat a similar deliverable in the following period.

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.

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.

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. Generating the link also puts the deliverable into review and sets a 30-day review deadline, if it didn't have one yet.

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.

The Approval field, in the details block, is the same control from the inside: No tag, Review requested or Approved. 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. 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. It's what Orion reads when you ask about that deliverable's content.

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.

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) 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). A deliverable can be removed from the plan later, with the Remove from plan button on its row.

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.

Step 3 — Sign

Once the portfolio is assembled, the ✍ Sign plan (manager) button appears. Signing is a manager's act (or an Admin's) — assistants assemble the plan, but don't sign for it.

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

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.

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. 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 (manager or 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.