Kowalah

Your 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_my_training

Return 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

Return 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_operating_model_unit

Return 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? }, kpis, deployments, outcomes, 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. 'kpis' are the measures the process is judged by: baseline, target and current value (measured_at is when the current value was recorded), with progress.fraction along baseline → target, direction-aware. 'deployments' are the units that run the process, live first. '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_process

Your 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_systems

Get 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_update

Return 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_get_vision

Propose 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_process_change

Create 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. Each carried step keeps how it runs today, including its execution platform and linked systems. 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_propose_redesign

Record 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 and ask_why: "undecided" when it is not new; ask_guide says what to ask for each on the ones the user has not yet described (ask_about counts them). Pass verbose: true for full records.

kowalah_record_ai_assets

Record 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_outcome

Add 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 } }.

kowalah_save_person