# Decide when the founder needs to review work Version 1.1 · Kramaniti Kosh ## Intended outcome A short set of rules that say which work needs founder sign-off and which can move with a lighter check, so the founder stops being a permanent review queue. ## Before you begin - A list of the recurring work that currently waits on the founder - Named people who can act as deputy or peer reviewer when a lighter path is allowed - A shared place for the rules that the team can find again ## How to use 1. List the work categories that keep landing in the founder’s queue. Keep the list to what already happens, not every imaginable case. 2. For each category, choose one default path, write why, set a time limit and name the escalation if work gets stuck. Leave blanks visible rather than guessing. 3. Review the rules when a new category appears, a lighter path fails, or a founder-only trigger is missed. Money, legal exposure or a new customer promise stays with a named human the same day. ## Working template ## Review rules header Team or organisation: Rules owner: Where these rules live: Last reviewed: ## Work categories List the recurring review queues. Examples of categories you may already have: client proposals, public website copy, hire offers, refunds or credits, new tool connections, routine internal drafts. ## Rule table Record one row per category. - Category - Default path (Founder must review / Named deputy may approve / Peer check then proceed / Log and proceed) - Why this path - Time limit or SLA note - Escalation if stuck ## Founder-only triggers These always need the founder or the named decision owner, even if the category usually has a lighter path. - Money: fees, discounts, refunds, credits or new spend beyond an agreed limit - Legal: contracts, liability language or regulated claims - New customer promise: scope, delivery date, service level or outcome not already sold in writing - Brand-new claim: a public or client-facing claim the organisation has not used before - Irreversible system change: access, data deletion, production publish or a tool connection that cannot be undone quickly ## Lighter-path conditions A named deputy, peer check or log-and-proceed path is allowed only when all of these are already true. - The work fits a category in the rule table - No founder-only trigger applies - Sources, evidence or an approved standard for that category are available - The deputy or peer is named and present for that path - The decision or send will be logged where the team can find it ## Stop rules - If any founder-only trigger applies, stop the lighter path and send the work to the founder or named decision owner. - Do not treat “named deputy may approve” as permission to invent a new promise, price or public claim. - A peer check without a named peer, or a log-and-proceed path with no log, is unfinished; use founder review or wait. - If the time limit passes with no decision, escalate as written in the rule table rather than waiting in silence. ## Demonstration This is an illustrative scenario, not a client case study or a measured result. Do not reuse its details as facts about your work. A sample six-person boutique architecture studio in Bengaluru designs small commercial fit-outs. The founder reviews almost every proposal, website update, hire note and tool request. Routine work waits even when a senior associate or studio manager could safely decide. ### Sample inputs Demonstration inputs only: six recurring queues. (1) Fee proposals for fit-out projects under a set size. (2) Public website project pages. (3) Offer letters for junior hires. (4) Supplier credit notes under a set amount. (5) New design-tool logins that touch client files. (6) Internal meeting notes and mood boards. No usage numbers beyond these six queues. ### Example output #### Row 1: fee proposals under the set size [Fact within this demonstration] Fee proposals currently wait in the founder’s inbox even when they reuse the studio’s standard rate card. Default path: Named deputy may approve. Why: The rate card and scope checklist already exist. Time limit: [Two working days]. Escalation: Founder. [Inference] The deputy path only holds while the proposal stays inside the written rate card and checklist. #### Row 2: public website project pages [Fact within this demonstration] Project pages go live on the studio site and may include claims about outcomes. Default path: Founder must review. Why: Brand-new claim and public wording. Time limit: [Before publish]. Escalation: Hold publish. [Recommendation] Keep public pages on founder review until an approved claim list exists. This recommendation is not the founder’s decision. #### Row 3: junior hire offer letters Decision path: Named deputy may approve when the role, salary band and start date match a band the founder has already written down. Owner for deputy path: [Name the studio manager]. Escalation: Founder if the band is new or unclear. #### Row 4: supplier credit notes under the set amount [Fact within this demonstration] Credits touch money. Default path: Founder must review above the set amount; Named deputy may approve at or below it when the supplier invoice is on file. [Recommendation] Keep anything above the set amount with the founder. Do not auto-approve credits. #### Row 5: new design-tool logins that touch client files Default path: Founder must review. Why: Irreversible system change and client file access. Owner: [Name the founder]. Time limit: [Before the login is created]. #### Row 6: internal meeting notes and mood boards Default path: Log and proceed. Why: Internal only, reversible, no client promise. Condition: No client-facing send and no new claim. Log owner: [Name the project lead]. ## Quality check Every category has one default path, a reason, a time limit and an escalation; founder-only triggers are written down; lighter paths name the deputy or peer and the log; blanks stay visible rather than filled with guesses. ## Limits and human review The rules record who may decide; they do not prove a decision was wise, lawful or safe. A lighter path is not approval for money, legal wording or a new customer promise. Keep consequential actions with the named human owner. ## Edition notes New in Kosh at version 1.1. Provider-neutral Markdown instructions; no installation or platform compatibility is implied. Runtime behaviour has not been verified across AI providers. Reuse terms have not yet been published. Background reading: [Founder Review Should Be Conditional, Not Constant](/insights/founder-review-should-be-conditional-not-constant/). Conditional review rules after launch are part of Kramaniti’s [Complete Lifecycle Retainer](/#services).