# Modules: domain power without losing the core

> Canonical HTML: https://initkoa.org/platforms/orgo/modules
> Markdown mirror: https://initkoa.org/platforms/orgo/modules/index.html.md
> Route: /platforms/orgo/modules
> Source: app/platforms/orgo/modules/page.mdx
> Generated: 2026-04-09T23:01:26.288Z

[Open the HTML page](https://initkoa.org/platforms/orgo/modules)

Blocks,
Building2,
Hospital,
GraduationCap,
Landmark,
Wrench,
Users,
Shield,
ArrowRight

"Orgo modules adapt Orgo to a domain (HR, maintenance, healthcare, education, public services) without changing the core guarantees: routing, escalation, auditability, and offline resilience."

# Modules: domain power without losing the core

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 **domain views** (how teams browse and filter their work)

### Modules never change
- the Case/Task accountability model
- escalation logic (time-bound work stays time-bound)
- auditability and traceability
- offline-first operation

## Choose a module (common starting points)

title="Maintenance & Facilities"
description="Incidents, work orders, safety follow-ups, and recurring infrastructure issues—captured, assigned, escalated, and closed with outcomes."
href="/platforms/orgo/use-cases"
title="HR & People Operations"
description="Onboarding/offboarding, role changes, grievances, approvals, and compliance—handled as accountable work, not inbox chaos."
href="/platforms/orgo/use-cases"
title="IT Support & Security"
description="Access requests, incident response, device lifecycle, and security follow-ups—clear ownership, strict response windows, traceable actions."
href="/platforms/orgo/use-cases"
title="Education Operations"
description="Student support, administrative coordination, scheduling, and institutional follow-ups—so learning isn’t blocked by bureaucracy."
href="/platforms/orgo/use-cases"
title="Healthcare Operations"
description="Care coordination workflows, service handoffs, inventory requests, and operational follow-ups—reliable execution under pressure."
href="/platforms/orgo/use-cases"
title="Public Administration"
description="Citizen requests, permits, inspections, and inter-department coordination—transparent closure, no lost files, no silent backlog."
href="/platforms/orgo/use-cases"

## Pre-built packages vs custom modules

### Pre-built packages
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.

## Next

href="/platforms/orgo/adoption"

href="/platforms/orgo/guarantees"