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
- List the work categories that keep landing in the founder’s queue. Keep the list to what already happens, not every imaginable case.
- 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.
- 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. Conditional review rules after launch are part of Kramaniti’s Complete Lifecycle Retainer.