Work plans, execution and cycles

15. Work plans

A work plan belongs to one worker — a person or an AI worker — and covers one period (usually a month). Inside it you spread that person's availability across the deliverables they commit to, as a percentage of effort, and describe what they promise to do on each one.

Two things make it different from a task list: it is signed by both parties, and the signature automatically creates the period's assessment cycles. With no signed work plan there is no cycle, no report and no structured feedback.

The #1 blocker for every new manager

Before you create any work plan, the team needs a signed deliverables plan. This is the rule that surprises newcomers the most, so it comes first.

To create (and later sign) a work plan, the person's team — or a team above it in the hierarchy — needs a deliverables plan that is, at the same time:

• signed by the responsible management, and
• in In progress or Planned (signed and not started yet).

A deliverables plan in Draft will not do. A draft is not a plan: it is a text nobody has reviewed. The signature on the deliverables plan is the moment the scope was reviewed — and it is what authorizes committing a person to that scope.

The system refuses at both moments, with different messages depending on the case:

There is no deliverables plan

"This team has no deliverables plan in progress yet. Create and sign the team's deliverables plan (or that of a team above it) before creating work plans."

It exists, but was not signed

"This team's deliverables plan exists but HAS NOT BEEN SIGNED by the board. Work plans can only be built on signed deliverables — the signature is the review of the scope."

The creation screen already warns you when the team has no active deliverables plan, and disables the button. The signature check happens when you save and again when you sign — because a deliverables plan can lose its signature in a revision after the work plan already existed.

If you are setting the operation up from scratch, the order is

create the team → create the deliverables → build the team's deliverables plan → sign the deliverables plan → only then create the work plans.

Creating the plan (the structure)

In Work Plans → New work plan, you define the structure. Deliverables come in on the next screen.

Team member

who the participant is. A manager, assistant or Admin creates a plan for the people they manage; someone with only the member role creates a plan for themselves alone.

Team

normally pre-filled with the person's home team. For an AI worker the field is mandatory — an agent has no home team, and it is the plan that puts it on the team.

Start date and end date

the plan's period.

Feedback frequency

Weekly, Bi-weekly, Monthly or "At the end of the work plan". This is where the cycle duration comes from — 7, 14 or 30 days, or a single cycle covering the whole period. You do not type the duration: the number of cycles is derived from period ÷ duration, and the screen shows the math ("4 cycles (period ÷ duration)").

Cycles end on (optional)

fixes a day of the week for the end of every cycle, if you want every cycle to always close on a Friday, for example. Left blank, the cycles run consecutively from the start date.

Working days

calculated on its own — weekdays in the period minus national holidays. You can adjust it up or down (vacation, part time), and the availability in hours follows (hours per day × working days).

Adding deliverables and setting the effort

Once the plan is created, you land on its page. Use ＋ Add deliverable.

The picker first asks which deliverables plan — with the team's active plan already pre-selected — and also offers the option "All active deliverables (any team)". Tick the deliverables in the checkboxes and click Add (n).

There is no authorization step for taking a deliverable from another team. Contributing to another team's deliverable is an exception the method allows for, not a mistake: the picker offers every active deliverable in the organization and the system accepts it. The only real block is the canon — the deliverable has to be in a signed deliverables plan. For a person that produces a warning; for an AI worker, it blocks the signature (more on that below).

For each deliverable you add, fill in:

Effort %

how much of the available time in the period goes to that deliverable. E.g.: 40% for "New method tested".

What will be done (the promise)

the promise, in text. E.g.: "Contact the volunteers and close the participation list for the test by the 10th." This field locks when the plan is signed.

The Total effort number appears at the top of the page. It is not capped at 100%: above 100.5% the number turns red, as a warning, and nothing stops you from signing like that. The decision is yours — sometimes the sum goes over on purpose, and the system does not pretend to know better than you.

Not every piece of work becomes a deliverable. Use ＋ Other work for what consumes time and produces no deliverable, in three categories: Support, advisory & training, Team & deliverables management and Other (not linked to deliverables).

Pointing at the tasks

When the deliverable is broken into tasks — the most common case — the plan must say which tasks that person works on. One, some or all of them. On the plan page, under "Tasks you'll work on", tick the tasks being taken on.

This matters more than it looks: the task is what defines the deliverable's progress. A plan that points at deliverables but at no task gets the red "no tasks" tag in the Work Plans list, with the explanation: "The plan points at deliverables but at no TASK. A work plan must say which tasks the member works on — pointing at the deliverable is not enough."

For a person this is a warning, and you carry on. For an AI worker, it prevents the signature.

If the deliverable has no tasks yet, there is a Suggest tasks button that lets AI propose a breakdown from the deliverable's title and context — you review it before anything is created.

Signing: what the signature does

The plan has two signature lines, Participant and Supervisor, and each one has its own button.

Participant line

only the plan's owner signs (or an organization Admin).

Supervisor line

only a manager (or an Admin) — holding the manager role on some team is enough; the system does not check whether it is the plan's team. An assistant does not sign in the manager's place — that is the one work plan power the assistant role does not have, along with assessing cycles.

Before any signature, the plan needs at least one deliverable. An empty plan is no agreement at all, and the system refuses.

The confirmation says exactly what will happen: "Signing locks the plan's scope, creates the assessment cycles and freezes the Combinado." Three effects, and each one is worth understanding:

Scope locked

with both signatures, you do not add or remove deliverables from the plan. To change it, there is the Editing flow (below).

Cycles created

the system generates the period's cycles according to the chosen frequency, numbered (#1, #2, #3…). It is the only way cycles get created.

Combinado frozen

the Combinado in effect (the working agreement) — organization → team → person — is photographed inside the plan. By signing, both parties also agree to it, and later changes to the team's Combinado do not retroactively change what was agreed here.

Self-managed plans. A manager who is the plan's own participant signs both lines — participant and supervisor — alone. A second manager is not needed. Whoever answers for the team answers for their own plan too.

As soon as both lines are signed, the stage becomes Agreed — or already In progress, if the plan's start date has passed.

The ten stages

The old manual listed six. There are ten, and the four "extras" are real states you will see on screen.

Request adjustment (before the agreement)

If you receive a plan to sign and think it needs to change, use Request adjustment. The button appears only in the Pending agreement stage — that is, while one party has signed and the other has not.

The plan does not go back to Draft: it goes to its own Adjustment requested stage, and both signatures are cleared. Both parties have to sign again after the change. The other party is notified.

Both the participant and a manager (or assistant) can ask for the adjustment.

Changing a plan that is already under way

After the agreement, "Request adjustment" disappears — changing a signed agreement goes through a four-step flow, with two passes through management. This is the Editing flow:

1. The participant asks. The ✎ Request editing button, available to the plan's owner when it is Agreed or In progress. Managers are notified.
2. The manager authorizes entry. On approval, the system takes a photograph of the current scope (deliverables, effort, promises and task links) and unlocks editing. On refusal, the plan goes back to its previous state with no change at all.
3. The participant edits and submits. They adjust the deliverables and the effort and click Submit editing. The scope locks again.
4. The manager decides. Approve changes keeps everything and the plan carries on in progress with the new scope. Reject changes reverts exactly to the photograph from step 2 — what was added is removed, what was removed comes back, and effort and promises return to the agreed value.

The signatures stay in place through the whole process. The manager's approval is the re-agreement — there is no need to sign again.

Here, unlike signing, assistants can approve or reject both management passes.

What happens on its own, by date

Every half hour the system sweeps the plans and moves whatever the date calls for:

• Agreed → In progress when the start date arrives.
• In progress → Finishing when the end date passes.
• Finishing → Finalized only when all of the plan's cycles are Consolidated.

That last one is the one that usually raises questions. "Finishing" means: the period is over, but some cycle is still in the middle of the report, the feedback or the review window. The plan closes when the last cycle closes — not before.

When a plan is finalized, the platform invites you to log a closing note: what worked, what you would do differently. It is not mandatory, and it becomes reusable precedent for the next period.

Copy, delete, distribute

⧉ Copy is the standard renewal path. Copying a plan creates a new one already carrying the same deliverables, effort and promises; you give the owner, period and frequency again. It is far faster than rebuilding month by month.

🗑 Delete draft only works on a plan in Draft with no signature at all. Any signature, even a single one, makes the plan undeletable — because from that point on it is a recorded commitment, not a working document. Deleting the draft also removes the deliverables and tasks that were in it.

✨ Generate work plans for the team sits on the deliverables plan page. AI distributes that plan's deliverables among the team's active members and shows the proposal — with the allocated percentage and the tasks per person — before creating anything. You review it, send it back for another proposal if you did not like it, and only then confirm. The plans are born in Draft, to be signed normally.

AI worker plans

An AI worker has a work plan too, and the mechanics are almost the same. The differences that matter:

The team is mandatory. An AI worker is not a user and has no home team. It is the work plan that puts it on the team — allocating it to the team and giving it direction are the same act.

One live plan at a time. Overlapping periods for the same agent are refused. People can have more than one plan; agents cannot.

The manager's signature is enough. When the manager signs the supervisor line on an agent's plan, the agent counter-signs its own line right away.

The canon blocks instead of warning. A deliverable outside a signed deliverables plan, or a deliverable broken into tasks with no task pointed at: for a person that is a warning; for the AI worker the signature is refused with the list of violations. The reason is simple and deliberate — a person knows when the exception is legitimate and answers for it; the agent does not have that judgment, and a worker nobody can hold to account is the worst possible combination.

Through Orion, without opening the dashboard

Almost everything in this section also happens in conversation. Some examples of what to say:

• "create a work plan for Ana, from September 1 to 30, weekly feedback"
• "add the deliverable 'Guide X written' to Ana's plan with 30% effort"
• "which work plans are waiting for my signature?"
• "sign my work plan"

Copying a plan is the exception: you do that on screen, with the ⧉ Copy button. Orion does not have that command.

Orion runs with the same permissions you would have on screen. If the server refuses — no signed deliverables plan, you do not hold the manager role — it passes the reason back instead of inventing a way around it.

16. Executing and tracking

With the plan signed, the part nobody can fully automate begins: doing the work and recording what was done. The platform asks for little logging, but what it asks for feeds everything else — progress, risk, cycle report and assessment.

Where progress gets updated

On the task. Each task has a 0 to 100% bar. You drag it and that is it — the most frequent record, and the cheapest.

On the deliverable. The deliverable's progress is computed, not typed: it comes from the tasks' progress, weighted by each task's weight. The deliverable page shows the bar with the "Progress (computed)" label, a progress-over-time chart and a Gantt with the planned bars, today's line and each task's actual start.

On the work plan. Each deliverable on the plan has a "What was done" field, per cycle. This is where the participant writes, over the course of the cycle, what they actually accomplished on that deliverable. That text is what becomes the cycle report.

Recurring deliverables work differently: they have no deadline and never reach 100%. What you record on them is the value achieved per period ("in July we closed 340 support cases"), and the page shows the series period by period.

The dashboard

The Dashboard consolidates the organization live: deliverable counts, active work plans, active people and teams; budgeted hours and budgeted cost from the planned effort; distribution by deliverable status and by plan stage; and the top 10 deliverables by hours/cost. There is a filter by team.

A privacy detail worth knowing: cost and salary values are stripped on the server for anyone with the member or assistant role. It is not the screen hiding them — the number never leaves the server.

Situation: the summary written by AI

The work plan page, the deliverable page and the deliverables plan page each have a Situation card. Clicking Generate, the AI compiles in text what that person committed to do, what they accomplished across the cycles, the blockers and the trend — split into Progress, Challenges and Outlook.

The situation is saved. When there is new work since the last compile, the card warns you ("There's newer activity since this was written") and offers Refresh. It is not recompiled on every visit, so the AI cost stays under control.

The decision log: the "why"

Below the work plan (and the deliverable, and the deliverables plan) there is a block for logging decisions: lessons, retrospectives and explained deviations, with the cause tagged. It becomes available as soon as the plan is agreed — there is no decision to log on a draft.

The habit is worth it. That archive is what feeds the Lessons tab in Reports and what makes Orion, over time, recommend in a way that resembles yours. "We decided to postpone module B because the client changed the priority" is a ten-second sentence that avoids the same discussion three months from now.

Reports

The Reports page is restricted to admins, managers and team assistants — it contains per-person assessments. It has three tabs:

Reports

periodic reports on the team's work, generated from the real work recorded on the platform. They open in a new tab through a link that expires. When there are assessments or entries made in the period after generation, the report shows "n new signals" and can be regenerated — the previous version is preserved.

Maturity

how the measured signals evolve from one report to the next — average star rating, cycles assessed, decisions logged, deliverables updated, active people, average progress at period end, positive signals (%) and friction signals. It appears once at least two periods have been generated.

The series only shows what is comparable from one period to the next. "Deliverables at risk" and "automatable tasks" were left out on purpose: they are only known at today's value, so two periods would display the same number and the comparison would be false. You still see both inside each report, as a snapshot of the moment.

Lessons

the organization's archive of lessons, retrospectives and deviations, with a Generate insights (AI) button that points out what keeps working in your favor, the recurring frictions and recommendations — always saying how many entries it was based on.

"Am I the bottleneck?"

Ask Orion that and it lists everything stalled waiting on you, in six categories: work plans to sign, cycles to assess, appeals (review requests), edit requests, deliverables plans to sign and deliverables to close. And it settles right there in the conversation whatever can be settled.

17. Cycles, feedback and review requests

The cycle is the unit of conversation about performance. It is born with the work plan's signature, has a duration derived from the feedback frequency the two of you chose, and always runs the same sequence: the participant reports, the manager answers with stars and a comment, the participant can request a review, and the cycle consolidates.

The deadlines below are the ones the system actually applies. If you saw 10/30/10 in some old material, that is wrong: they are 5 / 10 / 5.

The states of a cycle

Not initiated

the cycle has not started yet.

In progress

the cycle is running. The participant fills in "What was done" on each deliverable as they go.

Pending report

the cycle ended and the report is expected.

Awaiting feedback

the report was submitted (or the deadline passed with no report) and the ball is with the manager.

Feedback given

the assessment was recorded. It is still mutable — the 5-day window to request a review or for the manager to adjust is running.

Review requested

the participant contested it and the manager has to respond.

Consolidated

final state. Immutable.

The timeline, with the real deadlines

In the worst case — nobody submits a report and nobody assesses — a cycle resolves itself 15 days after the end of the period, and consolidates 5 days after that.

Step 1 — the cycle report

The report comes from what you wrote in "What was done" on each deliverable. There is no separate form: the Submit cycle report button compiles those texts and sends them to the manager.

The submission window is wider than it looks:

Before the end

the button opens on the last day of the cycle. Week ended on Friday and you want to send it right away? You can. Through the rest of the cycle the button stays visible but disabled, telling you the date it opens.

On time

the 5 days after the end of the cycle.

After the deadline

if the 5 days passed with no report, the cycle moves on to "Awaiting feedback" marked as no report — and you can still submit, as long as the manager has not given the feedback. A late submission clears the mark.

Missing the deadline, then, does not block the cycle and does not prevent the assessment. What happens is that it moves ahead with a visible mark, and the manager is told the report is missing (distinct from "report ready").

Once the report is submitted, it freezes: the fields are locked while the cycle awaits the feedback.

Step 2 — the manager's feedback

Assessing a cycle is an act of the team manager (or an organization Admin). Assistants do not assess. HR does not assess.

The manager opens Give feedback ★, picks 1 to 5 stars and writes the comment. The participant is notified.

If the manager does not act within 10 days — counted from the submission of the report, or from the end of the cycle + 5 days when there was no report — the system applies an automatic neutral 3★ feedback, with a generated justification that says exactly that, and notifies both parties.

This is not a self-assessment: the 3★ are the system closing a cycle that went unanswered, neutrally and openly — not a rating the participant gave themselves.

There is also no separate self-assessment step on the platform: whoever records stars always holds the manager role (or is an Admin). On a self-managed plan — the one where the manager is the participant — this means they assess their own cycle, and the record carries their name.

Dormant organizations are left out of this automation. If nobody in the organization has signed in or done anything on the platform in the last 30 days, cycles do not advance on their own and nobody gets an email — the automation resumes when someone comes back.

The star scale

The full descriptions appear at assessment time, so a star is never just a number. 3 stars is "Solid Performance": "Reliably delivered quality work that met the core objectives for the period. A consistent and valued contribution."

The scale above is the default — your organization can rewrite it. The title and description of all five stars are editable on the Organization page, with a "Reset to default" button. Admin edits them; HR does too — it is the only organization setting open to the HR role. Which means the labels you see on your screen may be your company's, not these.

The mandatory justification

On 5★ and on 1–2★ the comment is mandatory: without it the system refuses the assessment. This is not bureaucracy — these are the two extremes where the rating, on its own, teaches nothing.

On 5★

record what made the work exceptional, to serve as a reference for the team. Highlight specific achievements where productivity and quality lifted the results in the period.

On 1–2★

clearly and kindly describe what did not go as expected (productivity, quality, or both), the impact on the team and concrete steps to grow. The history is recorded to track progress over time.

Step 3 — requesting a review

Anyone who receives a 1 or 2 star feedback has 5 days, counted from the date of the assessment, to request a review through the Request review button — adding their point of view on that period. Once the deadline passes, the system refuses the request and the rating is final; the screen shows the ✓ final tag.

The manager answers in one of two ways:

Accept the request

the cycle reopens in "Pending report". The participant revises "What was done", resubmits, and the manager assesses again.

Refuse

the assessment stands and the cycle moves on to consolidation. The participant is notified of the refusal.

If the manager does not respond within 5 days, the request lapses and the original assessment stands.

Within that same 5-day window the manager can also adjust their own feedback without anyone having asked — the Adjust feedback button. An adjustment restarts the 5-day window, giving the participant a fresh chance to speak up about the revised rating.

Consolidated: the end of the line

Once the 5 days pass with no review and no adjustment, the cycle becomes Consolidated. That is the terminal state: final and immutable. Nobody reopens it, nobody reassesses it, and the work plan is only finalized when all of its cycles get here.

That is why the 5-day window exists and is short. With weekly cycles, the goal is for each round to close before the next one ends — feedback that arrives months later no longer changes anything.

The record that stays

Each assessment freezes an immutable performance record for that period: who, on which team, in which cycle number, with the exact period, the commitment made (the promise on each deliverable), the report submitted, the total effort, the stars, the justification and whether there was a review request.

That record is independent of the work plan — if the plan is deleted later, the person's history still stands. It is what holds up Reports, the Maturity view and the organization's memory of the work that was actually done.

Cycles through Orion

As in the previous chapter, all of this happens in conversation:

• "submit the cycle 2 report on my work plan"
• "which cycles are waiting for my feedback?"
• "give 4 stars to Ana's cycle 3 and write: delivered the guide ahead of the deadline and helped the team on the test"
• "I want to request a review of the cycle 1 feedback"

The permissions apply the same way: Orion only assesses a cycle if you hold the manager role (or are an Admin), and it does not accept 5★ or 1–2★ without a comment — it will ask for the comment first.