kowalah_create_opportunity
ChatGPTSubmit a new idea, question, or ask to Kowalah. This is the single entry point for everything a customer might want help with — whether it's a quick question, a piece of work they'd like the Kowalah team to take on, a new initiative they're considering, or a project they want to scope. The customer doesn't need to decide in advance whether it's an expert request, a deliverable, or a project. They just describe what they're trying to do; Kowalah's team triages it from there. Anyone in the organisation — admin, core team, or member — can create an opportunity using this tool. Use this when the user says things like "I need help with…", "can you raise an opportunity to…", "I've got an idea about…", "we should look into…", "raise this with Kowalah". What a complete submission carries: - content of at least a paragraph. The server rejects anything shorter than the minimum length. - an ICE score (impact / confidence / ease, each 1-10) with a short rationale for each. Optional in the schema, but an unscored opportunity is slower to triage. For a response to a discovery, the impact rationale relates to the discovery's business_value_context. - where the organisation has an AI vision map, the guiding principle the opportunity serves and the KPI it moves, named in the content. - discovery_id, when the opportunity answers a Kowalah discovery the user was invited to. Only call this once the user has confirmed the submission. It is submitted straight away: it appears on the discovery and to the organisation's core team at once, the same as an idea entered through the Kowalah app. Args: - title: Short title — one sentence summarising the ask - content: The detail — what you're trying to achieve, the context, what good would look like, anything Kowalah should know. Where the org has a vision map, include which guiding principle this serves and which KPI it moves. Plain string is fine; the server stores it as rich text. Aim for at least a paragraph (80+ chars). - organization_id: Which of the user's organisations this is for. Required. - score (expected): ICE assessment — { impact: { score 1-10, business?, productivity?, adoption? }, confidence: { score 1-10, rationale? }, ease: { score 1-10, rationale? } }. Use the impact slot(s) that fit: business (e.g. "£2M annual cost reduction in supplier spend"), productivity (e.g. "200 hours/week saved across support"), adoption (e.g. "drive ChatGPT login rate from 15% to 60%"). Composite is computed server-side. Partial scores are accepted but try to get all three numbers + a rationale per dimension. - department (optional): Which department this relates to (e.g. "Sales", "Operations") - source_note (optional): Where this idea came from (e.g. "from yesterday's leadership meeting", "raised by a customer") - requested_target_type (optional): If the user has a strong view on the form of help — "deliverable" (a piece of work Kowalah delivers for them) or "expert_request" (a focused question/answer with an expert). Omit if they're unsure; Kowalah's team will decide together with the client. - requested_project_id (optional): If this opportunity relates to an existing project, the project's UUID - discovery_id (optional): If the user is responding to a Kowalah discovery, the discovery's UUID (from the user's pending_discoveries). The server validates the caller is on the discovery's audience, stamps the opportunity with the discovery and its project, and marks the audience invite as responded. Returns: The created opportunity with its number (OPP-…, how the user refers back to it) and your_recent_opportunities, the user's own queue.
kowalah_find_accelerator
ChatGPTSearch Kowalah's accelerator library: proven skills, plugins, prompts, guides and templates the user can take off the shelf instead of starting from scratch. Use it when the user asks "have we done this before?", "is there a template for X?", or describes a need that may already be met, and before raising a new opportunity. Each accelerator is one job with an edition per AI platform (Claude, ChatGPT, Copilot, Gemini, or any assistant). Each edition says how to get it (download, read or watch, open a link, copy a prompt), how to use it and its version. Results also carry a security summary (what it can read or do, whether a person approves its actions) and a link to its page in the Kowalah app, where files are downloaded. You see the organisation's own accelerators plus Kowalah's library. 'access' is "full", or "preview" for a Kowalah accelerator on a plan without the full library (what it is and does, without the payload). Args (all optional): - id: one accelerator's full view (whole prompt or guide, the files inside a skill, its SKILL.md) - query: free text - kind, family, audience, platform: filters - pcf_element_id / process_step_id: accelerators for a place in the process taxonomy, or for a step in the user's operating model - scope: all (default), kowalah, organization - limit: default 20, max 50 Returns: { total, count, accelerators: [...] }, or { accelerator } for an id.
kowalah_find_person
ChatGPTLook up people in your organisation by name, to get the person_id that owner fields take: a process owner, a step owner, an eval owner, a unit leader, or the owner of a system or AI asset. Everyone the organisation has added is listed, whether or not they have a login: someone who never signs in to Kowalah can still own a step. has_login says which. People who have left are listed last with has_left: true; they keep what they owned, but can't be named as a new owner. query is partial and case-insensitive; omit it to list everyone. If more than one person matches, the right one is the user's call. If nobody matches, the person hasn't been added yet: an admin can add them on the Operating model › People page in the web app. Returns { kind: "people", organizationId, count, people: [{ person_id, name, has_login, has_left, position, home_unit: { id, name } | null }] }.
kowalah_get_ai_estate
ChatGPTYour organisation's AI estate: every AI asset recorded (connectors, skills, plugins, projects, agents, automations, apps), with its platform, owner, status, scope, who has seen it and where, and the process steps it runs. Use it for "what AI have we actually got?", "what's been built?", "which agents run which steps?", "what's personal / shadow AI?", "what has gone quiet?". 'gaps' comes first and is what to act on: - no_owner, undecided (still 'discovered'), scope_unknown - stale: nobody has recorded it from their session for 90 days - not_in_model: an agent, skill, automation or app that runs no process step - needs_auth: connectors someone has installed but not authorised (or that are disconnected / not set up) - personal: assets that belong to one person (scope 'user'), with platformSanction - acts_unsupervised: connectors that can act (send, sign, write) with nobody approving - connection_concentration: people holding 3+ connections (who, for admins and core team) - in_house: what your organisation built itself - unsanctioned: shadow AI — assets on a platform the organisation has not approved (no approved arrangement in the systems register) or has prohibited, personal ones first Pass unit_id for the assets running steps in one part of the business, or origin (e.g. in_house). Each asset shows its origin and version, whose login a connector runs on and what it can do, and how many outcomes it produced; with id, the outcomes themselves. With id: one asset with its sightings, the assets inside it, and the steps it runs. The register is only as complete as the people who have shared their tools, so a short register may be an incomplete one.
kowalah_get_my_training
ChatGPTYour Kowalah training: what you're scheduled into, your agenda, and how you're getting on. Use this for "what training am I booked on", "what's my schedule", "how am I doing", "did I pass". kind: - "enrolment" (default): the training programmes and events you're a participant in — titles, dates, location, your group, status. - "schedule": your day-by-day agenda (sessions, times, rooms, topics) for the events you're in. - "progress": YOUR own record — attendance, module/quiz results, AI-fluency scale scores, badges earned, certificates, your feedback, and your commitments. - "org_overview": an anonymised, aggregate view of training across your organisation (enrolment, attendance %, completion, average feedback). Available only if you are an admin or core_team member; everyone else gets a not-permitted note. This only ever shows your own training (matched to you by email / account) — it never exposes other participants, their results, or internal trainer notes. If you're not enrolled in anything, it says so.
kowalah_get_operating_model
ChatGPTReturn your organisation's AI Operating Model as a unit tree with coverage roll-ups on every node (coverage %, process count, redesign-gap count, constraint count — rolled up across each unit's whole subtree), plus org-wide totals and a narratable summary. Use this for the "world view": how much of the business AI could support today, and where the gaps and constraints concentrate. Args: - organization_id (optional): Required only if you belong to more than one organisation. Also returns a vision block when your organisation has an AI vision map. By default it is a summary: the vision statement and its guiding principles (detail: "summary"). Pass include_vision: true for the full map with attributes and measures ({ ownership, owningUnitName, vision: {...} }). Absent when no vision has been authored yet. Args (continued): - view (optional): 'tree' (default) or 'rows'. - backlog_limit, question_limit (optional, rows view only, default 50, max 500). Every answer carries 'definitions': one line per figure (what coverage, gaps, priced gaps, constraint steps, annual hours and readiness mean). view 'tree' returns { kind: "operating_model", tree: { organizationId, totals, units: [...nested, each with leaderName...], summaryMarkdown }, definitions, vision?: {...} }. view 'rows' returns the whole model in one call as flat lists, for dashboards and reports: { kind: "operating_model_rows", rows: { organizationId, totals, units, processes, backlog, openQuestions, counts }, definitions, vision }: - units: one row per unit in tree order, with path, depth, parentName, leaderName and its subtree roll-up. - processes: one row per live process (to-be redesigns appear on their as-is process, not as rows), with unitName, owner names, its roll-up, openQuestionCount and readiness { ownerSet, stepCount, stepsWithTouchTime, stepsWithElapsed, fullyTimed, stepsWithTarget, stepsWithDecision, redesignMarkedUp, toBe, toBeProposed, stepsWithImplementations, stepsWithLiveImplementations }. - backlog: the org-wide redesign backlog, ranked, each with processNumber, processName and unitName. - openQuestions: newest first, each with processNumber, stepName and unitName. - counts: how many backlog steps and open questions exist against how many were returned. - vision: the group vision's measures (baseline, target, target date, values and progress), or null when your organisation has no vision map. Group-wide hours are not reported on this connector and read null, which means "not reported", not zero. Returns kind: "empty" when no operating model has been mapped yet.
kowalah_get_operating_model_unit
ChatGPTReturn one org unit: its subtree coverage roll-up, the processes it owns directly (each with its own roll-up), its child units, and the top redesign-backlog steps across its processes (ranked constraint × coordination burden). Args: - unit_id (required): The org unit's UUID. - backlog_limit (optional, default 5, max 500): how many backlog steps to return. - question_limit (optional, default 10, max 500): how many open questions to return. openQuestionTotal says how many exist. Each backlog entry names its process (processNumber, processName). The unit carries leaderName and each process customerOwnerName. 'definitions' says what each figure means. Also returns a vision block resolved FOR THIS UNIT — its own vision map if it has one, otherwise the nearest ancestor's with ownership: "inherited" and the owning unit named. By default it is a summary (statement and principles, detail: "summary"); pass include_vision: true for the full map. Returns { kind: "unit", portfolio: { unit, rollup, processes (each with openQuestionCount), childUnits, topBacklog, topOpenQuestions, openQuestionTotal, summaryMarkdown }, definitions, vision?: {...} }. topOpenQuestions are the most recent unanswered questions across every process in this unit and below it. Returns kind: "no_match" when the unit isn't in your scope.
kowalah_get_process
ChatGPTReturn one process in full: its metadata (purpose, cadence, criticality, owners, owning unit), its ordered steps with current→target dispositions, gap/constraint markers, the DEFINE contract (acceptance_criteria, input_artifact, output_artifact), per-step implementation links and per-step quality evals (gate/monitor checks with target vs current scores), a process-level roll-up, the ranked redesign backlog, its inter-process connections, and the initiatives already aimed at it. Use it for "walk me through this process", "why does X take so long", "where are the bottlenecks". Args: - process_id (required): The process's UUID. Returns { kind: "process", detail: { process, rollup, steps, backlog, connections, initiatives, diagnosis, summaryMarkdown }, notes: { counts, open_questions, all? }, access: {...} }, or kind: "no_match" when the process isn't in your scope. 'notes' is what has been LEARNED about the process: evidence, observations, decisions and open questions, added through the save tools' notes field. open_questions are the unanswered ones. The default shows open questions and says what else exists ('not_shown'); pass include_notes: true for the full log grouped by step. diagnosis.openQuestionCount and diagnosis.evidenceLastRecordedAt say how settled the process is. Each step carries systemIds and systems: the systems from your organisation's systems register that it runs on. 'outcomes' is the value realised on this process and its steps (on.type process or process_step), with totals per comparable unit: claimed and verified apart, one-off and recurring apart. Archived steps are left out of the model. Pass include_archived_steps: true to get them as 'archived_steps', with every field, to check an archive, restore one, or recreate it. A connection pinned to an archived step is flagged (thisStepArchived / otherStepArchived). 'diagnosis' is the derived read of how well this process is actually CAPTURED. It carries touch_minutes_total (a floor — read it with steps_missing_touch), handoff_count, distinct_owners, constraint_steps, steps_missing_output, steps_missing_acceptance_criteria and steps_with_exception_notes. Its counting rule: a null means "can't say", never "none". handoff_count is null whenever any step lacks an owner, because a partial count would understate the handoffs. It also carries 'cycle' — where the TIME goes, as against where the hours are — and 'chased_steps'. cycle.ratio is touch time over elapsed time across the whole chain, and it is NULL unless every step is both timed and costed, because a ratio built from three of twelve steps makes a process look tighter than it is. When it is null, cycle.steps_untimed says which steps are missing a timing. 'access' reports what YOU may do to this process — relationship ('at_own' | 'below' | 'at_peer' | 'above' | 'lateral'), can_edit, can_create and can_propose. When can_edit is false, an edit is refused and a proposal is accepted. 'initiatives' lists the opportunities / deliverables / projects linked to this process, with step_id / step_name when a link is pinned to one step. It is filtered to what you personally may see, so it can legitimately differ between colleagues.
kowalah_get_systems
ChatGPTYour organisation's systems register: the tools and platforms the work runs on, whether each has AI in it, and how you hold it (arrangements: tier, seats, contracting party, DPA, training on data, admin control, audit trail, sanctioned status). Use it for "what AI tools do we have?", "which tools are unsanctioned?", "who pays for ChatGPT?", "what renews soon?", "where is Claude used?". Modes: - Register (no id): every system with its arrangements and how many live steps use it, plus 'flags': unreviewed arrangements, risks (employee-contracted, no DPA, trains on data, no admin control, no audit trail, prohibited in use), AI systems with no arrangement recorded, systems in no process step (not_in_model), and renewals due in 90 days. Pass ai_only: true for the AI Register view. - One system (id): the system, its arrangements, and used_in: every live step and process that runs through it. Catalogue systems (scope 'global') come from Kowalah's shared catalogue and cannot be edited, but you can record your arrangements on them. Commercial fields (annual cost, currency, payment route, renewal date, renewals_due) are shown to admins and core team only; 'commercial_fields' says whether they are included.
kowalah_get_update
ChatGPTGet a status update from Kowalah. Use this for any "how are things going", "what's the status of X", "give me an update", "what have I raised recently", "how is the discovery going", "who am I" question — the server figures out whether you mean a portfolio rollup, a focused view of a specific project / deliverable / expert request / opportunity / discovery, or simply your identity and organisations. What you get back depends on the user's role: - admin / core_team see every project, deliverable, expert request, client-visible risk and discovery in their organisation, and every submitted opportunity. - members see their own opportunities plus projects / deliverables / expert requests where they're a stakeholder, and discoveries they've been invited to. Anything they're not a stakeholder on is invisible — a "no_match" for a known reference number usually means they're not on that item, not that it doesn't exist. For a discovery (DISC-…), admin / core_team get the brief, how many invitees have responded, and the submitted ideas ranked by score. An invitee gets the brief, their own invite and what they've submitted to it. Args: - query (optional): A natural-language description of what you want a status on. Examples: "how are things", "the website project", "ER-42", "DISC-0001", "the procurement opportunity". Leave blank for a portfolio / home view. - since (optional): A date (YYYY-MM-DD) or date-time. Returns what's new since then instead of a status view; query is ignored when since is set. Returns: An object with a 'kind' field describing the shape: - kind: "home" — identity + organisations + role-appropriate rollup. May include a 'privileged' section (admin/core_team orgs) and/or a 'member' section (member-only orgs). - kind: "project" / "deliverable" / "expert_request" / "opportunity" / "discovery" — focused view, with children filtered to what the user is allowed to see. A discovery view carries member_view: true when the caller sees it as an invitee rather than as admin / core_team. - kind: "ambiguous" — multiple things matched; pick one and call again. - kind: "no_match" — the query didn't match anything visible to the user. Returned even when an item with that name exists but the user isn't permitted to see it. - kind: "whats_new" — what has been added since the given date. 'covers' lists what the answer includes (currently accelerators). 'accelerators' holds those added to the user's library since then, newest first, each with its scope, the date it was added, and access ("full" or "preview"), plus 'total' and 'returned'.
kowalah_get_vision
ChatGPTReturn your organisation's AI vision map — the vision statement, its guiding principles with their defining attributes, and the success measures. This is the top altitude of your AI Operating Model: the output of your AI Vision Day, in your own words. Use it for "what is our AI vision?" and "does this idea fit our vision?". Each principle carries defining attributes as an assertion plus a counter-clause ("It moves a business KPI." / "Not a good idea in search of one."). The pair is the test of whether something fits the principle. The vision is owned by an org unit. Passing unit_id resolves what that unit should be looking at: its own map if it has one, otherwise the nearest ancestor's, flagged inherited. Omit it for the group vision. Args: - organization_id (optional): Required only if you belong to more than one organisation. - unit_id (optional): Resolve for one unit rather than the group. Returns { kind: "vision", vision: { ownership: "own" | "inherited", owningUnitId, owningUnitName, lastUpdatedAt, vision: { …statement, principles, programmeMeasures… } } }, or kind: "empty" when no vision map has been authored yet.
kowalah_list_opportunities
ChatGPTList your organisation's opportunities (OPP-…), filtered and paged — the whole backlog, including ideas raised outside any discovery. Who sees what: admins and core team see every submitted opportunity in the organisation. Members see the ones they raised. Each row carries: id, opportunity_number, title, status, department, discovery_id, ice ({ composite, impact, confidence, ease }, null if unscored), rationale (a short line per ICE dimension), summary (the first 280 characters of the write-up as plain text), merged_into_opportunity_id, promoted_to_type / promoted_to_id, declined_reason, created_at. Statuses: captured (new), shortlisted, parked, rejected, merged (folded into another idea), promotion_requested, promoted (became an expert request, deliverable or project). Args: - organization_id (optional): only needed if you belong to more than one organisation. - discovery_id (optional): only ideas raised in that discovery. - status (optional): array of statuses to include. Default: all. - department (optional): exact department name, case-insensitive. - order_by (optional): "score" (default, highest ICE composite first) or "created" (newest first). - limit (optional): 1-100, default 50. - cursor (optional): next_cursor from the previous page. Keep the other filters the same. Returns { organization, kind: "opportunities", scope: "organisation" | "your_own", total, returned, opportunities, next_cursor }. next_cursor is null on the last page.
kowalah_promote_opportunity
ChatGPTTurn one of your organisation's opportunities into work: a deliverable on one of your own projects, or a request for Kowalah to take it on. The same choice as "Take it forward" on the opportunity in the Kowalah app. Destinations: - own_project: creates a deliverable on one of your own projects straight away, at the Planning stage, for your team or a partner to deliver. No Kowalah approval, and Kowalah isn't notified. Pass project_id, or new_project_title to create the project too. Needs the Business plan or a Kowalah managed service. - ask_kowalah: asks Kowalah to take it on as a deliverable on a Kowalah engagement (project_id, or the only one you have). It waits as promotion_requested until Kowalah approves or rejects it. Before promoting, the ICE score needs its "why": at least one impact rationale (business, productivity or adoption), a confidence rationale and an ease rationale. Add any that are missing by rescoring the opportunity first. Can be promoted from captured, shortlisted or parked (ask_kowalah: captured or shortlisted). Expert requests are raised in the Kowalah app. Permission: admins and core team of the organisation. Args: - organization_id (optional): only needed if you belong to more than one organisation. - opportunity_id: the opportunity's UUID. - destination: own_project | ask_kowalah. - project_id: own_project: one of your projects. ask_kowalah: the Kowalah engagement. - new_project_title: own_project only, to create a new project of your own. - title: own_project only, a title for the deliverable (defaults to the opportunity's). Returns { organization, kind: "opportunity_promotion", destination, opportunity, ... }: own_project adds project and deliverable (with its app url); ask_kowalah adds engagement and next. if_updated_at is the opportunity's. dry_run checks everything and returns action "dry_run" with what it would create and change, without saving. When calling this from a page or form: save once the value is final (on submit or blur, never on each keystroke), send one write at a time and wait for it to finish, pass if_updated_at on updates and an idempotency_key on creates, and send null (not an empty string) to clear a field.
kowalah_propose_process_change
ChatGPTPropose a change to a process you cannot edit directly (its access block reports can_edit: false). It files an opportunity linked to that process (and optionally to one step), so the owner can pick it up. Use it for "this step should be automated", "the acceptance criteria here are wrong", "we should add a quality gate" — anything you would change if it were yours. Anyone in the organisation may propose against any process they can see. Nothing about the process itself is modified. Args: - process_id (required): The process the proposal is aimed at. - process_step_id (optional): Pin it to one step. - title (required): Short summary of the change. - content (required): What should change and why. Returns { kind: "process_change_proposal", opportunity: { id, opportunity_number, title }, process_id, process_step_id }.
kowalah_propose_redesign
ChatGPTCreate a TO-BE version of a process, held beside the original so the two can be compared. WHY THIS EXISTS AND EDITING STEPS DOES NOT COVER IT. A step's disposition (human / ai_assisted / automated / ai_autonomous) says who RUNS the step, and every one of those values keeps it. Editing dispositions can only ever produce the same process with better paint. This is the tool that can say "these ten steps become three". The to-be is SEEDED from the as-is and from the redesign decisions already recorded on its steps: steps marked 'eliminate' or 'merge' do not come across; everything else does. A process whose steps already carry redesign_decision and redesign_rationale produces a redesign that reflects those decisions; one with none produces a copy. A step with NO decision is CARRIED, not dropped, and reported back in undecided_count. Silently deleting work nobody decided to delete would be the worst possible default. Two things are deliberately NOT copied onto the to-be. The target disposition is cleared, because the redesign is a new design question and inheriting the old target pre-answers it. And elapsed time is cleared, because it is the number the redesign exists to MOVE — carrying it over would make the comparison show a saving of zero until somebody noticed. The result is a real process (status 'draft', redesign_status 'proposed') with its own number. Nothing about the as-is changes. Competing options are allowed: each call creates another to-be beside the as-is. Permission: the same rule as editing the process — you may redesign a process you own or one at or below your unit, as the process's access block reports. Args: - process_id (required): the as-is process's UUID. Returns { kind: "redesign", redesign: { id, process_number, name, step_count, carried_count, dropped_count, undecided_count } }.
kowalah_record_ai_assets
ChatGPTRecord the AI tools your organisation uses: connectors, skills, plugins, projects, agents, automations and apps. Use it when the user shares what THIS session uses, and to record what they tell you about each one. It is for what the user has seen and agreed to share: only names and ids are stored. Recording: pass each item with its kind, name and, whenever the surface shows one, external_ref (a connector's installed server id, plugin_…, skill_…, a project id). Pass surface. Known assets are "seen again" (their last-seen date moves); new ones arrive as status 'discovered', scope 'unknown'. Put plugins first and give the skills inside them parent_external_ref. Record a connector that is installed but not authorised with connection_status 'needs_auth'. Leave out built-in and local tools (memory, file system, the browser): they are not the organisation's estate. PRIVACY — it stores names and identifiers only: not a skill's instructions, a prompt, a tool's description or a project's contents, and not a description inferred from them. A project shows an id but not its name, so its name comes from the user. Personal projects are not part of the organisation's estate. Decisions (description, owner, status, scope, archive) record what the user says, not a guess. Admins and core team decide about any asset; anyone may mark something as their own personal asset (scope 'user'), and an owner may update what they own. A refused decision still records that the tool is used. Recording needs edit rights on the operating model; a viewer can read the estate. serves_step_ids links an asset to the process steps it runs (e.g. the agent that drafts replies), so the process shows it on those steps. Platforms: what this session uses is linked to the platform its surface runs on (Claude for Claude's surfaces, ChatGPT for ChatGPT and Codex) when the systems register holds it, and a connector to the system it is named for (the HubSpot connector reaches HubSpot). Pass system_id / reaches_system_id to say otherwise. Returns one short result per asset (action created | seen_again | updated | ambiguous | refused, id, kind, name, gaps, and what was linked) with ask: true on the new or undecided ones, which the user has not yet described (ask_about counts them). Pass verbose: true for full records.
kowalah_save_discovery
ChatGPTRun your organisation's own discovery: ask people across the organisation where AI could help, then triage what comes back. Actions: - create: a draft under one of your own projects (project_id, name; optional goal, close_date, business_value_context, target_opportunity_count). - update: change the brief. Before launch everything can change; after launch only name, target_opportunity_count and a later close_date. - add_audience: invite people (people: [{ email, name? }]). People already on the list are skipped. - remove_audience: take people off (emails). - close: a live discovery stops taking ideas and moves into triage. Launching sends the invitation emails, which happens in the Kowalah app: create and add_audience return launch_url. A discovery needs a goal, a close date and at least one person before it can launch. Discoveries run by Kowalah (under a Kowalah engagement) are managed by Kowalah and are refused here. Reading a discovery is a status update, not this tool. Needs the Business plan or a Kowalah managed service. Permission: admins and core team of the organisation. Returns { organization, kind: "discovery_saved", action, ... }; update also returns changes ({ field: { from, to } }). if_updated_at is checked on update and close, against the discovery itself. dry_run returns action "dry_run" with the changes, would_create, would_add or would_remove, without saving. A repeated idempotency_key on create returns the first discovery with idempotent_replay: true. When calling this from a page or form: save once the value is final (on submit or blur, never on each keystroke), send one write at a time and wait for it to finish, pass if_updated_at on updates and an idempotency_key on creates, and send null (not an empty string) to clear a field.
kowalah_save_org_unit
ChatGPTCreate or update an org unit — a node of your organisation's operating-model tree. Modes: - Create: omit 'id'. Required: unit_type, name. For a child pass parent_id (the organisation is inherited); for a ROOT unit pass organization_id. - Update: pass 'id'. Only provided fields change. Pass parent_id to re-parent within the same organisation. Pass process_order to reorder the unit's processes in one go. Permission: you may create a child unit under a unit at or below your own, and edit a unit you lead or one below you. Creating a ROOT unit reshapes the top of the org chart and is restricted to admins and core team. Returns { kind: "org_unit", action: "created" | "updated", org_unit: { …domain shape… } }.
kowalah_save_outcome
ChatGPTRecord realised value from AI work: time saved, cost reduced, revenue won, an adoption milestone. On any work, not only Kowalah's: a process step, a process, a unit, an opportunity, the whole organisation, or a Kowalah deliverable or expert request. Record what the user tells you, in their words. Ask how they know (the basis: estimated, sampled or measured) and don't upgrade a guess. Give a comparable unit (value_unit, plus currency for money, any currency) and a period whenever there is a figure, or it can't be added up. Link what produced it (ai_asset_id, e.g. the agent that runs the step) and what it counts towards (vision_measure_id) when you know. Modes: - Record: omit id; pass on, title, narrative, outcome_type (and the figure). source defaults to client. - Update: pass id. Only whoever recorded it, or admins and core team. Changing the figure of a verified outcome makes it a claim again. - Verify: id + verify: true. Admins and core team only, in their own name. - Remove: id + remove: true. Returns { kind: "outcome", action, outcome: { ..., annualised, gaps } }. gaps say what stops it being trusted or added up: not_comparable, no_period, no_basis, no_evidence, unverified.
kowalah_save_person
ChatGPTAdd someone to your organisation's operating model, or change them: their name, email, altitude (position) or home unit, or mark them as having left. The same people the Operating model › People page lists. Use it when an owner field needs someone who isn't there yet. Look them up first and only add them if nobody matches (an email already in the organisation is refused). A person needs a name or an email. They don't need a login: someone who never signs in can still own a step. Adding an email does not invite them; inviting is done on the People page. Only the fields you pass change. Marking someone as left keeps what they own, so reassign it. Someone who signs in changes their own email in their account, so it can't be changed here. Permission: admins of the organisation only (the People page's manage_members). Everyone else is told to ask an admin. Returns { kind: "person", created, person: { person_id, name, email, has_login, has_left, position, home_unit_id }, changes? }. changes lists each updated field as { from, to }; dry_run returns action "dry_run" with them (or would_create) without saving. A repeated idempotency_key returns the first person with idempotent_replay: true. When calling this from a page or form: save once the value is final (on submit or blur, never on each keystroke), send one write at a time and wait for it to finish, pass if_updated_at on updates and an idempotency_key on creates, and send null (not an empty string) to clear a field.
kowalah_save_process
ChatGPTCreate or update a process in your organisation's AI Operating Model. Modes: - Create: omit 'id'. Required: name, org_unit_id (the owning unit — it fixes the organisation). The process number is allocated automatically, and customer_owner_person_id defaults to the owning unit's leader. - Update: pass 'id'. Only provided fields change. Pass org_unit_id to re-parent within the same organisation. Order: position sets where the process sits in its unit (1 = first); omit it and a new or moved process goes to the end. To reorder a whole unit at once, update the org unit with process_order. Permission: you may create in a unit at or below your own, and edit a process you own or one at or below your unit. Admins and core team may edit anywhere in the organisation. Setting position changes the unit's order, so it also needs edit rights on the unit (one you lead or one below you). Anything else is refused, with a message saying a proposal is accepted instead. Returns { kind: "process", action: "created" | "updated", process: { …domain shape… } }.
kowalah_save_process_connection
ChatGPTCreate, update or delete a connection between two DIFFERENT processes: a handoff ("qualified deals pass to Proposal") or a feed ("closed-won stories feed the content pipeline"). Connections are what make the operating model a graph rather than a list; a process read shows them under 'connections'. Modes: - Create: omit 'id'. Required: from_process_id, to_process_id, connection_type. Optionally pin either end to a step (from_step_id must belong to from_process_id, to_step_id to to_process_id). - Update: pass 'id'. You may change connection_type, note, and the step endpoints. You cannot re-point the processes: delete and recreate instead. - Delete: pass 'id' and delete=true. Permission: a connection changes both processes, so you need edit rights on BOTH ends (admins and core team may edit anywhere in the organisation). Without them the change is refused. Returns { kind: "process_connection", action: "created" | "updated", connection: {...} } or { kind: "process_connection", action: "deleted", id }.
kowalah_save_process_step
ChatGPTCreate or update a step within a process. Modes: - Create: omit 'id'. Required: process_id, name. position defaults to append; current_disposition defaults to 'human'. - Update: pass 'id' (process_id is derived from the step). Only provided fields change. DEFINE contract: acceptance_criteria (the bar the step's output must meet), input_artifact and output_artifact capture the step's I/O. Its quality checks (evals) are separate records, not fields on the step. Jidoka rule: when the step's effective target_disposition is 'ai_autonomous', escalation_trigger is required (the stop-condition returning control to a human). A partial update that would leave the step autonomous without a trigger is rejected. Archive, never delete: archived: true (with archived_reason) takes a step out of the model and closes up the gap; archived: false restores it. A step is archived rather than recycled for something else, because a recycled record carries the wrong history. Systems: system_ids sets which systems the step runs on, as ids from the systems register (whole set; [] clears). This is also where a human step records the tool a person does it in: execution_platform is for what runs the step, and a human step cannot carry one. Notes: pass notes to record what you learned (interview confirmations, CRM findings, agent config, open questions) and resolve_notes to close them. Keep exception_notes for how edge cases are handled, and platform_detail for the platform. Pass reason to say why a change was made; it goes into the model's history. Permission: the same rule as the parent process — you may edit steps of a process you own or one at or below your unit; admins and core team anywhere in the organisation. Anything else is refused, with a message saying a proposal is accepted instead. Returns { kind: "step", action: "created" | "updated" | "archived" | "restored", step: { …domain shape… }, notes?: { added, resolved } }.
kowalah_save_process_step_eval
ChatGPTCreate or update an eval on a process step — the quality check that a step's output meets its acceptance criteria. This is how a business owner sets and tracks the bar: "what counts as a good forecast category call", "what a compliant response looks like". Modes: - Create: omit 'id'. Required: process_step_id, name. method defaults to 'human_review', mode to 'monitor', status to 'defined'. - Update: pass 'id' (process_step_id is derived from the eval). Only provided fields change. Gate vs monitor: a 'gate' blocks the step until it passes (all-or-nothing) and must NOT carry sampling_pct; a 'monitor' observes a sample and may set sampling_pct (0–100). Rejected if the effective state is a gate with a sampling_pct. Scoring: target_score is the bar, current_score the latest reading. You cannot set the measurement timestamp, the source, or the position — the server owns all three. Writing current_score stamps measured_at for you; clearing it clears the stamp. Permission: creating an eval needs edit rights on the parent process. Once created, the eval's owner_person_id may edit it thereafter even if the process itself sits above their altitude — so a function lead can own the eval on a process they do not otherwise control. Admins and core team may do either anywhere in the organisation. Returns { kind: "step_eval", action: "created" | "updated", eval: { …domain shape… } }.
kowalah_save_system
ChatGPTAdd a system to your organisation's register, update it, and record how you hold it (arrangements). Modes: - Create: omit 'id', pass name. A system of the same name already in your register is returned instead of a duplicate (action "matched_existing", fields unchanged: pass its id to update). If Kowalah's catalogue has one of that name, the catalogue system is used and your arrangements go on it (action "matched_catalogue"); pass own_copy: true for your own record instead. - Update: pass 'id'. Only provided fields change. A catalogue system (scope 'global') cannot be edited, but you can pass arrangements for it. - Retire: status: "archived". Systems are not deleted. arrangements: each item adds, updates (with id) or removes (id + remove: true) one way your organisation holds the system, e.g. "Claude Team, 50 seats, organization-contracted, DPA in place, approved" and "Personal Max plans, employee-contracted, unreviewed". Adding one with the same label and tier as an existing arrangement updates that one. Unset fields stay null, and null means "not assessed", which is different from false. sanctioned_status records a decision the organisation has actually made. Permission: admins and core team with edit rights on the operating model. Everyone in the organisation can read the register. Returns { kind: "system", action: "created" | "updated" | "matched_existing" | "matched_catalogue" | "unchanged", system, arrangements: [{ action, arrangement }] }.
kowalah_triage_opportunity
ChatGPTRecord a triage decision on one of your organisation's opportunities: shortlist, park, reject, revert, merge or rescore it. The same moves as the triage board in the Kowalah app; the person who raised it sees the outcome. Actions: - shortlist: a captured or parked idea goes on the shortlist. - park: worth revisiting later. - reject: not pursuing it. reason is required and is shown to the raiser. - revert: back to captured, from shortlisted, parked or rejected. Rejecting's reason is withdrawn. - merge: fold a duplicate into another opportunity (into_id). Both must be in the same discovery (or both raised outside one). The source becomes 'merged', points at the target, and its contributors are added to the target. Merged is final. - score: change the ICE score. Pass any dimensions in score; the rest keep their value. Each changed number is recorded in the score history with its old value. Not allowed on promoted, merged or rejected opportunities. Promotion into an expert request, deliverable or project is not done here. Permission: admins and core team of the organisation. Args: - organization_id (optional): only needed if you belong to more than one organisation. - opportunity_id: the opportunity's UUID. - action: shortlist | park | reject | revert | merge | score. - reason: required for reject; optional for the others and posted as a comment on the opportunity. - into_id: for merge, the target opportunity's UUID. - score: for score, { impact?: { score?, business?, productivity?, adoption? }, confidence?: { score?, rationale? }, ease?: { score?, rationale? } }, scores 1-10. Returns { organization, kind: "opportunity_triage", action, previous_status | previous_score, opportunity, ... }. A merge also returns merged_into and contributors_added; a score returns history_recorded. dry_run returns action "dry_run" with what would change, without saving. When calling this from a page or form: save once the value is final (on submit or blur, never on each keystroke), send one write at a time and wait for it to finish, pass if_updated_at on updates and an idempotency_key on creates, and send null (not an empty string) to clear a field.
kowalah_create_opportunity
Claudekowalah_find_accelerator
Claudekowalah_get_ai_estate
Claudekowalah_get_my_training
Claudekowalah_get_operating_model
Claudekowalah_get_operating_model_unit
Claudekowalah_get_process
Claudekowalah_get_systems
Claudekowalah_get_update
Claudekowalah_get_vision
Claudekowalah_propose_process_change
Claudekowalah_propose_redesign
Claudekowalah_record_ai_assets
Claudekowalah_save_org_unit
Claudekowalah_save_outcome
Claudekowalah_save_process
Claudekowalah_save_process_connection
Claudekowalah_save_process_step
Claudekowalah_save_process_step_eval
Claudekowalah_save_system
Claude
