Document how the work actually runs.

Processes are easy to describe after they fail and surprisingly difficult to find while they are working.

The problem

Workflows, ownership and escalation paths are often reconstructed from memory at the moment they are needed.

What goes in the repository

Workflows
Responsibilities
Dependencies
Escalation paths
Recurring processes
Operational decisions
Checklists

operations/
├── index.md
├── processes/
├── ownership/
├── dependencies/
└── checklists/

Why an open repository helps

An explicit process can be followed, reviewed and corrected. An implied process has to be rediscovered.

How Okide helps

Okide keeps the working process in files you can update when the work changes, with history for what used to be true.

Humans and agents, same files

Operational agents can follow explicit processes and surface the source knowledge behind an action.

OPEN BY DEFAULT

Keep the repository. Change the tools around it.

The process is useful when someone can find the current version before something breaks. Okide helps you work with the repository without turning it into an Okide-only format.

Learn about Open Knowledge Format → Download Okide — free

Related use cases

TEAMS

Runbooks

Keep operational knowledge readable and current.

runbooks/api-outage.md

Explore →

COMPANIES

Policies & procedures

Keep important rules versioned and reviewable.

policies/security.md

Explore →

COMPANIES

Internal documentation

Keep documentation in portable files.

docs/index.md

Explore →