Flows — how work moves in Orgo

Orgo is not just a queue.

It is a governed operational flow system: signals become cases, cases generate tasks, work is routed to the right function, escalations happen when time windows are missed, and outcomes are recorded with enough evidence to be reviewed later.

This page is the map of that movement.

The core flow

In Orgo, the operational path is simple:

1. A signal arrives
   Email, form, API event, field note, call log, or imported record.

2. A case is created
   The issue gets a durable identity, ownership context, and an audit surface.

3. The case is routed
   It goes to the right function, team, or role based on policy.

4. Tasks are generated or attached
   Work becomes executable and traceable instead of remaining a vague request.

5. Time windows are enforced
   If the case is not acknowledged or completed on time, Orgo escalates.

6. Closure is recorded
   The result is explicit: what happened, who acted, and what evidence exists.

7. Patterns feed reviews
   Repeated failures, delays, or anomalies become review material instead of disappearing.

What this changes in practice

The flow stack

Think of Orgo flows as four stacked layers:

1) Intake

How signals enter the system.

This can be:

• email,
• forms,
• APIs,
• imports,
• field submissions,
• or internal reports.

The key principle is simple: incoming messages are normalized into work candidates.

2) Routing

How the case finds the right owner.

Routing can use:

• function,
• category,
• location,
• urgency,
• confidentiality,
• and policy rules.

The point is to remove ambiguity from “whose job is this?”

3) Execution

How the case becomes real work.

Execution in Orgo means:

• assign ownership,
• create tasks,
• enforce response windows,
• track state transitions,
• and record handoffs.

This is where operations stop being “conversation” and become governed movement.

4) Review

How the organization learns.

Orgo does not stop at closure. Repeated failures, slowdowns, duplicates, and policy friction can trigger:

• reviews,
• audits,
• pattern analysis,
• and structural fixes.

That is how flows become an improvement system, not just a ticket trail.

The main flow pages

What “good flow design” means in Orgo

A good flow is not just fast.

A good flow is:

• clear — ownership is explicit
• bounded — time windows are defined
• auditable — decisions leave a trace
• contestable — errors can be reviewed and corrected
• resilient — the system still functions during degraded conditions
• improvable — recurring friction becomes visible

This is why Orgo flows matter more than ordinary task boards: they are designed for public accountability and operational continuity, not just team convenience.

How flows relate to modules

Flows are not domain-specific by themselves.

The same underlying flow can support:

• a municipality,
• a hospital,
• a justice system,
• a field NGO,
• or internal organizational operations.

Modules adapt the same flow logic to a specific domain vocabulary and operational context.

Example: one flow in plain language

A resident reports a dangerous water leak.

• the signal arrives,
• a case is created,
• it is routed to the correct municipal function,
• a response timer starts,
• if nobody acknowledges it, Orgo escalates,
• a field task is created,
• closure is recorded with evidence,
• repeated failures in the same zone can trigger a review.

That is a flow: not a message, not a vague promise, but an accountable movement from signal to outcome.

Why this page exists

This page is the navigation layer for Orgo’s operational movement.

Use it when you want to understand:

• how work moves,
• where responsibility is enforced,
• how closures become provable,
• and how operational patterns become reviewable.

Next