Operating allocation — current-state audit (2026)
Status: In progress (Phase 1 — MCP + REST inventory; person directory hygiene Apr 2026; Linear / plan reconciliation next)
Parent plan: Operating allocation audit (2026)
Tracking: PLT-1224 · PR #529 · Operating REST/skills PR #816
Purpose
Execute step 1 of the parent plan: document how allocations are actually used in delivery, surface pain from real conversations, and list what still requires direct access to Operating (objects, fields, RBAC) to complete the audit.
Evidence from vault (delivery usage)
Summaries below are from internal transcripts; they are not a substitute for a product inventory inside Operating.
| Theme | What showed up | Source |
|---|---|---|
| Accuracy / trust | Allocated hours disputed as not matching reality; prompts to update hours to a specific weekly target (e.g. “at least 30 hours per week until…”). | knowledge/clients/unassigned/transcripts/2026-03-12_pranav_-_brylle_-_abc_allocations_monthl_246fecaf.md |
| Tooling / access | References to “operating MCP” and whether automation or integrations are working; friction if MCP or workflows fail. | Same transcript |
| Financial tie-in | Question whether deal amount lives in Operating for deriving sensible hour budgets; conclusion that it may not be in Operating and may live elsewhere (e.g. vault). | Same transcript |
| Planning dependency | Leadership wants allocations formalized to plan roadmaps and pace; allocations called out as blocking effective planning. | knowledge/clients/unassigned/transcripts/2026-03-18_abc_roadmap_and_allocations_final_check-_6b174ec2.md |
| Ops / systems direction | Discussion of putting data in “a database in operations” and whether certain items “get into operating.” | knowledge/clients/unassigned/transcripts/2026-03-17_operations_weekly_sync_809a4ba4.md |
Hypotheses (updated after Operating MCP)
- Planning vs deal economics — Projects expose
billingType(e.g.fixed-price,time-and-materials,non-billable),currency,projectNumber, and client; there is no deal-size field in thelist_projectspayload. Deal economics still live outside Operating or in notes/CRM unless added elsewhere. - Update path — MCP exposes create/update/delete allocations and positions; writes are available to the authenticated user’s Operating permissions. ETL (
operating_to_snowflake) uses REST withOPERATING_API_KEYfor bulk mirror. - Stale data — MCP surfaces position-level
allocationRange(from/through) separate from allocation rows (time blocks withfrom/throughandpercentage). Mismatches between ended position ranges and active client work are an exception class to scan (see exceptions below).
Operating MCP snapshot (Brainforge tenant)
Captured: 2026-03-25 (Cursor agent, server user-operating). Tenant: Brainforge (org_zZMnto39qsCNMq2N, production, MCP enabled).
| Tooling | Notes |
|---|---|
list_tenants | Single membership for this auth user. |
list_statuses | Project + allocation statuses: Confirmed, Tentative (ids recorded in Operating). |
list_groups | Brainforge Team, External Contractors. |
list_roles | 23 active competence roles (DE, AE, DA, AI Engineer, CSO, Service Leader, etc.); nonBillable flag on role. |
list_sites | Brainforge Global + child sites USA, Europe, Pakistan, Phillipines (typo in Operating), weeklyWorkingMinutes 2400. |
list_people | 27 people (this page complete: hasMore: false); includes availability (7d/30d), activePositions summary, groupMemberships, primaryRole. |
list_projects | 27 non-archived projects (hasMore: false); types include Client, Internal, TimeOff; projectOwner, optional secondaryOwner, from/through, tags, groups. |
list_positions | 73 positions (hasMore: false); links assignedPerson, project, client, role, allocationRange, noteText. |
list_allocations | 100 allocations with fromAfter: 2026-01-01 (page complete per API); each row: positionId, from/through, percentage (see below), status, noteText. |
Percentage encoding: Allocation percentage is stored in millionths of full allocation (e.g. 250000 → 25%, 1000000 → 100%). Use this when mirroring to a warehouse or validating totals.
Inventory checklist (filled via Operating MCP + API shape)
| Area | Finding |
|---|---|
| Objects | Person → Position (person + project + role) → Allocation (scheduled blocks on a position). Project belongs to Client; optional Company, Site, Groups, Tags. |
| Fields | Positions: allocationRange (overall span). Allocations: date range + percentage + Confirmed/Tentative + notes. Projects: dates, billing type, currency, owners, status. People: roles, site, availability %, active position list. |
| Permissions | Not fully introspectable via MCP. Inference: MCP actions run as the signed-in user; read/write tools match Operating UI permissions for that user. Org-wide RBAC matrix still needs an admin screenshot or internal doc. |
| Audit trail | list_* returns current state only; no “last updated by” in these payloads. History belongs in Operating UI or raw API if exposed elsewhere. |
| Integrations | MCP (https://mcp.operating.app/mcp) for interactive agents; REST https://api.operating.app/v1 for Dagster → Snowflake (RAW_* tables). |
| Reports | Same data can be aggregated off mirrored Snowflake / future allocation_exceptions views per parent plan. |
REST snapshot (April 2026)
Captured: 2026-04-14 via https://api.operating.app/v1 (service API key). Canonical curl patterns: knowledge/standards/03-knowledge/engineering/setup/operating-api-setup.md.
| Area | Finding |
|---|---|
| Persons | 64 rows returned (GET /v1/persons); 26 active, 38 archived. Competence roles: 28 (GET /v1/competence-roles). |
| Person hygiene (remediated) | All 26 active profiles now have email and title (synced from Supabase team.role where applicable). |
| Hard-delete | DELETE /v1/persons/{id} returns 404; use PATCH archivedAt or UI/support for purging test rows (see playbook v1.6). |
| Allocations vs April | Query allocations?fromBefore=2026-05-01&throughAfter=2026-03-31 → 39 rows overlapping April; statusId values 573 / 574 (no GET /v1/statuses on this key). |
| Encoding | Allocation rows expose allocationPercentage (e.g. 5000 → 50% when divided by 100) alongside a larger percentage field; align ETL/docs with the field consumers actually use. |
| Anomaly | Robert Tseng — CSO row on Eden / Eden DE with allocationPercentage: 0 through early April 2026-04-03; fix in UI or PATCH allocation to a real % or end the row. |
Data-quality exceptions (flagged from MCP sample)
Review in Operating UI and reconcile with CSO/SL reality:
| Signal | Example / pattern |
|---|---|
| Missing project owner | LMNT Analytics — projectOwner: null. |
| Tentative + date drift | LMNT Data Platform — project status Tentative, through: 2026-03-01 (past relative to snapshot); confirm closed or renewed. |
| Tentative client deal | Jan’26-Ellie Mental Health - Deal #3 — Tentative project. |
| Position range vs active work | Several Eden DE positions show allocationRange.through in 2025-12-31 while the project through is 2026-04-27 — possible stale position span or intentional historical rows; verify ICs still mapped correctly. |
| Site label | Phillipines spelling on site name — cosmetic but affects reports/filters if searched as “Philippines”. |
Client priority by commercial value (HubSpot closed-won)
Purpose: Order the Operating ↔ Linear reconciliation pass starting with the largest closed-won commercial footprint (not ARR — sum of amount on deals where hs_is_closed_won is true).
Source (2026-04-14): HubSpot CRM deals search (private app token from 1Password → Brainforge Sales, e.g. Cursor HubSpot Sales Review app). 58 closed-won deals in scope.
Method caveats:
- Totals are sums of deal
amountgrouped by a parsed client token fromdealname(text before- Deal), so multi-entity names (e.g. ABC) may not matchclients.nameexactly; adjust manually when reconciling. Defaultis internal work in Operating but appears on HubSpot deals; keep in the pass if you want parity with CRM, or segment separately for “external only.”- Largest open pipeline deal (same day sample): CTA — $432,000 (
Feb'26 - CTA - Deal #3 - Shopify Digital Asset Store) — not in closed-won totals below.
Rank — closed-won $ by client bucket
| Rank | HubSpot bucket (from deal names) | Total $ (sum) | clients.name (when obvious) |
|---|---|---|---|
| 1 | LMNT | 523,000 | LMNT |
| 2 | Eden | 266,000 | Eden |
| 3 | CTA | 131,750 | CTA |
| 4 | Default | 126,483 | Default |
| 5 | ABC and Commercial Services | 125,500 | ABC Home and Commercial |
| 6 | Rimo Health | 110,000 | Rimo |
| 7 | Magic Spoon | 98,000 | Magic Spoon |
| 8 | Lilo Social | 70,000 | (no longer active in clients registry) |
| 9 | Pool Parts To Go | 57,750 | (inactive registry) |
| 10 | Urban Stems | 54,160 | Urban Stems |
Suggested Linear ↔ Operating pass order (active delivery registry first): LMNT → Eden → CTA → Default → ABC Home and Commercial → Rimo → Magic Spoon → Urban Stems, then remaining closed-won buckets if they re-engage or still have Operating projects.
Comparison to other systems (step 2 of parent plan)
- Export or snapshot current allocations — done via MCP (
list_allocationswindow from 2026-01-01; positions + projects full list for tenant). - Compare to Linear assignees/projects for active client work — next; run in HubSpot value order (see Client priority by commercial value above): start with LMNT, then Eden, CTA, Default, ABC, Rimo, Magic Spoon, Urban Stems. Use Linear MCP / board review per team; avoid huge cross-team queries.
- Compare to active client plans and CSO/SL narrative for the same week — human / vault.
- Tag each delta using parent plan taxonomy — in progress (exceptions table above).
Minimum viable truth model (draft)
Aligns to parent plan § “Audit workstream” item 4 — refine after inventory.
| Concept | Required? | Notes |
|---|---|---|
| Person | Yes | Stable id across HR + delivery |
| Service line | Yes | Matches Service Lead span of control |
| Client / workstream | Yes | Maps to how CSO/DL speak about demand |
| Role on assignment | Yes | IC vs lead vs shared |
| Hours/week or % | Yes | Operating allocations use percentage in millionths (1_000_000 = 100%); convert for leadership views. |
| Per-person total across clients | Yes | For delivery, sum active % for each person across all projects; flag ≥ 100%; warn 90–99%. See Per-person portfolio rollup. |
| Start / end / effective dates | Yes | For future changes |
| Status (active / tentative / ended) | Yes | Tentative must be visible, not buried in notes |
| Record owner (human) | Yes | One writer per row |
| Last confirmed at / by | Yes | Drives exception reporting |
| Source system id | Yes | For sync + idempotency |
Evidence requirements (Brainforge standard)
Proposal-grade allocation or commercial alignment (dates, billing type, leadership-facing roster %) should be triangulated from SOW (signed) + HubSpot + vault transcripts (and Slack when validating “who’s actually on this”). See .agents/skills/sl-allocation-updater/SKILL.md § Evidence gate.
Signed agreements (source of truth): Executed client agreements (SOWs, MSAs, order forms) are maintained in Google Drive: Client agreements folder. Vault copies under knowledge/clients/ are for search and context; if anything disagrees with the signed file in Drive, the Drive artifact wins until Finance/HoD records an amendment. Per-client folder + PDF links live in each operating-allocations-remediation.md under § Signed agreements (Google Drive — source of truth). Rolling verification template: operating-allocation-evidence-verification-2026-04.md.
Per-person portfolio rollup (delivery)
Goal: As allocation changes continue (LMNT, Eden, CTA, etc.), keep total planned % visible per person so nobody is accidentally modeled above full capacity.
| Step | Action |
|---|---|
| 1 | For each delivery person you touch, pull all active allocation rows that overlap the planning window (same effective dates). |
| 2 | Sum percentage millionths ÷ 1_000_000 (or sum % from each client’s remediation table). |
| 3 | Flag: ≥ 100% → must resolve (trim a client, end a row, or confirm intentional overload). 90–99% → warn (tight portfolio). |
| 4 | Vault per-client notes (knowledge/clients/*/resources/operating-allocations-remediation.md) are partial — a single spreadsheet or warehouse view per HoD sprint is ideal when many clients move at once. |
Automation (future): Parent plan + operating_to_snowflake can support a person × week rollup report; until then, Operating MCP list_allocations filtered by person or export is the manual check.
Next actions
- Allocation fix: Correct Robert Tseng 0% CSO allocation on Eden DE (or close the row if redundant).
- People / tenant reconciliation: Confirm whether 26 active people (REST Apr 2026) vs earlier MCP snapshot 27 matches expectations (archived filters / pagination / tenant).
- Remediation: LMNT / Eden / CTA / Magic Spoon / Amble / GlobalVetLink / ABC updates applied (2026-04-16 — see vault notes). Ellie skipped this sprint. LMNT Analytics owner only if
156984is unarchived. Next: optional passes for remaining active clients or warehouse rollup (per HoD). Re-verify LMNT Data Platform + Ellie tentative rows and Eden DE positionallocationRangeif still active. - Linear pass: Map each client project in Operating to Linear team/project and note assignee gaps (next automated pass when you want it).
- Permissions doc: HoD or Ops to export “who can edit allocations” from Operating settings into this doc or
knowledge/delivery/03-project-lifecycle/. - Portfolio rollup: On each allocation batch, sum per-person % across clients and flag ≥ 100% (see Per-person portfolio rollup above).
- Continuity: Evidence verification (rolling) — Current Operating baseline + Proposed next allocation moves + per-client transcript links for proposal-grade triangulation.
Client remediation queue (vault)
| Client | operating-allocations-remediation.md | Notes |
|---|---|---|
| LMNT | yes | 2026-04-16: legacy 145117 archived; single forward LMNT engagement from Apr 2026 = 171036 (Deal #2). |
| Eden | yes | 2026-04-16: PCC Brylle off 168008; delivery % → 40/28/20/12. |
| CTA | yes | 2026-04-16: four-person slice on 156976; duplicate Awaish allocation 2917347 zeroed via allocationPercentage: 0. |
| Ellie Mental Health | skipped (HoD) | Not in this remediation batch — revisit when prioritized. |
| Magic Spoon | yes | 2026-04-16: Deal #2 166208 — projectOwnerId → Demilade; 1381392 archived; allocations aligned 2026-04-01 → 2026-09-30. |
| Amble | yes | 2026-04-16: 154942 — owner → CSO holder 44556; through 2026-09-30; allocations extended. |
| GlobalVetLink | yes | 2026-04-16: 165633 — dates + T&M; allocations extended; Zoran vs Greg on CSO needs HoD (see note). |
| ABC | yes | 2026-04-16: 146949 — project through 2026-09-30; allocation grid unchanged in pass. |
Last updated: 2026-04-16 (merged main; retained REST follow-ups from 2026-04-14 snapshot)