This document defines how Kiluth writes operational documentation so it is easy to follow, easy to maintain, and safe to execute.
Outcome
A new teammate can execute the process correctly under time pressure, and the org can resolve conflicts using facts and links.
Scope
This standard applies to all Kiluth official operational docs across departments (Technology, Marketing, Finance, Legal, Delivery, Creative, HR, Account Management).
Includes
1
Tone and writing style
2
Minimum structure and formatting rules
3
How to write checkpoints / decision points and handoffs
Operating Model
Operating Model
1
Asana is the system of record for work tracking, approvals, and handoffs.
2
Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit.
Write for a real person doing real work. Assume they are busy. Reduce reading and cognitive load. Make each step easy to find and follow by breaking complex processes into granular, individual sections.
Simple
Prefer short sentences and common words. Remove filler (“in order to”, “it is important to”).
Minimal
Keep only what prevents mistakes or resolves common confusion. If it’s not used, remove it.
Concrete
Use “do X, paste link Y here, proceed when Z is true”. Prefer examples, templates, and checklists. Include numbered process descriptions within each step to show exactly what needs to happen.
Scientific / data-first
Prefer facts, artifacts, timestamps, links, and proofs over opinions and memory.
Structured
Use consistent headings, 2-column tables for processes/lists, and explicit owners for handoffs. Break each major step into its own section for easier navigation and comprehension.
Flexible
Define a default path, but allow exceptions via explicit decision points and documented deviations.
Document Structure (Minimum)
All Kiluth official docs should include:
Required
1
Title (H1)
2
Department line under the title (plain text)
3
## Table of Contents (always present; 2-column table)
4
A step-by-step section for the core workflow (when it’s a process doc)
5
Roles/owners for handoffs (who creates the next task / who approves / who links proof)
Recommended when relevant:
Recommended
1
Usage section (for process documents): Explains how to use the document step-by-step, what each section describes, and when to follow sections in order
2
Overview section (for process documents): Provides high-level context about the process flow before diving into detailed steps
3
Granular step structure: Break each major step into its own section (H2) rather than grouping all steps under a single “Step-by-Step Process” section. This makes the flow easier to follow and navigate
4
Process descriptions: Include numbered lists within each step showing what needs to happen (e.g., “PM estimation process: 1. Review scope, 2. Consider complexity, 3. Estimate range…“)
5
Asana card templates for handoffs (Title / Assignee / Description)
6
A short checklist at the end (only if the workflow has multiple handoffs/steps)
7
Decision points in an `Outcome
Language & Terminology Rules
Topic
Rule
“Gate” wording
Avoid “gate”. Use checkpoints for step validation and decision points for branching.
Sign-off
Prefer “sign-off proof” language and always make it linkable from Asana. If contract-related, require signed document.
Avoid policy-enforcement tone
Prefer “proceed when…” over “must / cannot” unless the rule prevents real risk.
Handoffs
Always specify: owner → artifact(s) → where to link → what “done” means.
Examples (Before / After)
Before (too vague)
After (Kiluth style)
“Make sure the client is aligned before proceeding.”
“Proceed when the client sign-off proof is linked in Asana: Sign-off proof: [Link] (meeting minutes or signed doc; signed doc required for contract-related decisions).”