Work catalog

The work catalog describes what your organisation does, independent of who does it. Each entry is a work activity — a unit of work such as "triage support tickets", "review merge requests", or "draft product requirements".

Activities are mapped in two directions:

Role types perform activities, each with a time share — the percentage of that role's time the activity occupies.
Teams are where activities concentrate, marked as primary or secondary.

Together these mappings give every role type and team a work profile: a structured answer to "what does this role or team actually spend its time on?"

Why model work?

Org structures describe reporting lines and cost. They do not describe work. When you are planning structural change — especially AI-driven change — the useful question is which work moves, automates, or disappears, and only then what that means for roles and teams.

A work catalog makes that analysis possible inside your organisational model instead of in a disconnected spreadsheet.

Where Work lives

Work is contextual, just like teams, positions, and people. The Live catalog records the activities performed today. Each planning scenario has its own copy, so it can change activities and their mappings without changing the baseline.

The work category taxonomy is different: categories are shared across the client tenant. Renaming a category therefore changes its label everywhere in that tenant, while changing an activity affects only the Live or scenario context you are viewing.

When a scenario is cloned from Live or another scenario, Orgonaut copies:

every Work activity in the source context
its category assignment
its role-type time shares
its primary and secondary team mappings, remapped to the teams in the new scenario

The copied activities are independent records. Later edits in the source do not flow into the scenario, and scenario edits do not alter Live. Cloning that scenario again uses its current Work catalog as the next source. Snapshots retain a read-only copy, while promoting a scenario makes its contextual Work part of the new Live baseline.

Activities

Each activity has:

a name and description
a work category from your tenant's taxonomy
a source recording how it entered the catalog: created manually, seeded from the starter template, or proposed by Astro and confirmed by you (recorded as assistant).

Required, optional, and Advanced fields

Orgonaut marks every editable field as Required or Optional. Required fields also have a red asterisk. The create and edit forms keep the essentials visible:

Required: activity name and category.
Optional (Advanced): description. Expand Advanced when the name alone does not explain what the activity involves or what “done” looks like.

When you add a role mapping, both the role type and time share are required for that row. When you add a team mapping, both the team and its primary or secondary emphasis are required. Adding a mapping row is itself optional; an activity may be saved before its role and team profile is complete.

Work categories

Categories are a tenant-defined taxonomy, managed in Settings → Work Categories — the same way team types and role types work. New workspaces start with five defaults: Delivery, Coordination, Judgment, Relationship, and Compliance. Rename them, recolour them, add your own, or deactivate the ones you don't use.

A category that is still classifying activities cannot be deleted — deactivate it, or recategorise those activities first.

Starter catalog

New workspaces begin with a curated starter catalog: around twenty common activities, pre-mapped to the default role types with sensible time shares. It is a starting point, not a prescription — rename, remap, or archive anything that does not describe your organisation.

If your catalog is empty (for example, in a workspace created before the starter catalog existed), the Work page offers a Load Starter Catalog action that adds the same set.

Generate a starting catalog with Astro

An empty catalog also offers Generate a Starting Catalog. Astro reads your role types — names, levels, and how many positions use each — and drafts a catalog tailored to them: activities with categories and role-type time shares.

The draft is a proposal, not a write. Astro shows you every proposed activity and mapping first; nothing is added until you confirm, and discarding the proposal leaves the catalog untouched. Activities created this way record their source as assistant, so AI-proposed entries stay distinguishable from manual and starter-template ones. Like any other activity, you can rename, remap, or archive them afterwards.

Activities can be archived when they no longer reflect how the organisation works. Archiving keeps mappings and history; archived activities are hidden from listings by default.

Time shares

Time shares are estimates, not timesheets. A role type's mapped activities can total less than 100% — most catalogs start sparse and grow. If a role's total exceeds 100%, Orgonaut shows a hint so you can rebalance, but does not block you: catalogs are iterated, not perfected.

Connect work to business capabilities

A Work Activity can be mapped to a contextual Business Capability assessment as core, supporting, or control work. This answers which activities actually produce or protect the promised business outcome. The optional contribution weight is descriptive; it does not allocate people or calculate value.

Make the mapping in the Capability workspace while viewing the same Live or scenario context as the Work Activity. Published AI Solution versions can claim supported Work categories, allowing Capability detail and a Transformation Case to surface candidate deployments without treating a category match as proof of an outcome.

Use Work across agency clients

Keep each client's Work catalog in that client's tenant. Consultants can be members of more than one tenant and switch between them, but Orgonaut does not share Work records across tenant boundaries.

Today, scenario cloning works only inside one tenant. There is no agency-wide Work library or one-click cross-client deployment. For a new client, use that tenant's starter catalog or let Astro propose a starting catalog, then adapt it to the client's language and operating model. This keeps confidential client data, mappings, and estimates isolated rather than silently reusing them elsewhere.

Working with the catalog

Work in the sidebar lists all activities with search and category filters.
Open an activity to edit its details and manage role-type and team mappings.
Team pages show the team's work profile.
The catalog is available via the REST API under work-activities endpoints, gated by the work.read and work.write token abilities.

Read Work with Astro

Astro can list and search Work Activities in Live, a scenario, or a snapshot. It can then inspect one activity by id or exact name, or use the Work detail page currently open in the overlay. Detail answers include the category, role-type time shares, primary and secondary team mappings, and a link back to the matching Work screen.

These reads use work.read and preserve the requested context. They do not create, edit, archive, or remap Work Activities. Generating a starting catalog remains a separate proposal-and-confirmation workflow described above.

Search Results