Orgo has a universal core that stays the same everywhere.
Modules are the layer that adapts Orgo to a specific domain:
vocabulary, forms, default handling patterns, and sector-specific workflows—without changing Orgo’s core guarantees.
The idea in one sentence
Same engine, different “skins” for real-world work.
A hospital, a school, and a municipality don’t speak the same operational language—modules let each domain work naturally, while keeping accountability consistent.
What modules change (and what they never change)
Modules can change
the domain vocabulary (what people call things)
the intake shape (what information is required to open a case)
the default handling patterns (typical routing, typical response windows)
the domain views (how teams browse and filter their work)
Modules never change
the Case/Task accountability model
function-based routing and collaboration
escalation logic (time-bound work stays time-bound)
Start with a module that matches your context, then adjust vocabulary and defaults.
This is the fastest path for small organizations and teams.
Custom modules (when you need them)
Large institutions can extend Orgo with domain modules that reflect their internal processes.
The goal is not complexity—it’s fit, while keeping the core guarantees intact.
