Skip to content
KoshKramaniti

ChecklistFree templateAdded 30 Sep 2026

Decide when the founder needs to review work

Set clear rules for what the founder must sign off and what can move with a lighter check.

Use it when The founder is the permanent review queue for proposals, copy, hires or tool changes, and work waits on them even when someone else could safely decide.

Download template

It is a simple text file. Open it in any text editor, or paste it into ChatGPT, Claude or Gemini and ask for help filling it in.

How to use it

  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.
What you will need before you start
  • 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

The template

Fill in the blanks for your business. This is what you get when you download or copy it.

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.
See an example

A made-up example, so you can see what a filled-in version looks like.

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].

How to tell it is done well

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.

Where a person should decide

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.

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.

Edit your own copy on this site
About this version

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.

How we write Kosh templates