HR management · embeddable module

HR that plugs into a product you already sell.

Cadre is a complete HR system packaged as a module. Your host product keeps its own authentication, sessions and tenancy — Cadre never asks you to change any of it, and never touches a table it doesn't own.

1
adapter interface to implement
0
foreign keys into your schema
2
deploy modes, one codebase
73
tests, isolation mutation-tested

The seam everything hangs off

An employee is not a user.

Every host product already has users, orgs and roles. Naive HR modules assume employee == user and break in week two — because employees who never log in still need payslips and leave balances, and host users who aren't employees must never appear in headcount.

cadre.person external_user_id text ← NULLABLE, and not a foreign key external_tenant_id text ← text, so the schema is identical embedded or standalone // Your product decides who is asking. Cadre decides what they may see. interface CadreHostAdapter { getPrincipal(req) // you own auth — we never guess sql // confined to the cadre schema files, mail, events features, packs }
Why this matters in practice: TaxPro gives a user one tenant. Custos gives a user many orgs with a role in each. No shared users table can serve both — so Cadre doesn't have one. That single constraint is what makes it portable.

Four decisions that can't be retrofitted

01

Effective dating, on two axes

Valid time records when a fact was true; recorded time records when we learned it. That's what makes a change different from a correction — and what lets a March payslip still be explained in September.

02

Positions, not just people

A position is a seat that exists whether or not anyone sits in it. Without it, vacancy tracking, headcount budgets and “this req backfills that exit” are simply unanswerable.

03

Business processes as data

Approvals are configured definitions that resolve by walking up the org tree. A region adds a step; every unit beneath it inherits without re-keying, and a new unit is correct the moment it's created.

04

Security granted positionally

Roles attach to positions and org units, not to people — so access follows a transfer automatically, and stops at the edge of the scope it was granted in. Revocation by default.


Why it stays pluggable

Every requirement that needs code creates a fork.

A customer needs an extra approval step. A developer adds it. That tenant now runs slightly different code. At three tenants it's annoying; at fifteen you can never ship a statutory rate update again without fifteen merges.

So configuration is the load-bearing requirement, not an ergonomic nicety. Leave types, employment types, approval routes, overtime multipliers, notification rules, review forms and security policies are all data — and behaviour reads flags on a row rather than branching on a string.

Configured, not coded

New leave type
a row
Extra approver over 20%
a step condition
Mumbai-only approval
a scoped definition
Night OT 1.5× → 2×
an effective-dated rule
“Blood group” field
a field definition
Regional HR, South only
a positional grant

Still deliberately code

Statutory floors
pack-supplied; raise, never lower
Tenant isolation
enforced, never configurable
Audit immutability
no admin can edit it
The expression sandbox
the allowlist is code

Configurability without governance is just a faster way to break production — so security changes stage as pending and need explicit activation.


Build order

Phase 0

The spine

built

Org tree, people, positions, effective dating, business processes, positional security, tenant isolation, audit, headcount reconciliation.

Phase 1

Leave & absence

engine built

Accrual engine, location holiday calendars, balances derived from a ledger, carry-forward and lapse, leave liability in currency.

Phase 2

Lifecycle & events

schema built

Onboarding and offboarding checklists driven by the BPF, document vault, outbound webhooks so Custos can revoke access on exit.

Phase 3

Attendance & overtime

engine built

Shifts, rosters, day classification, the premium rule engine with statutory floors, caps and an explain trace on every line.

Phase 4

India pack

structure built

Rate tables, statutory components, compliance calendar. Refuses a live run until its rates are verified against current law.

Phase 5

Admin console

planned

The five admin personas, the configuration surface, report builder, and opinionated preset bundles so nobody starts from an empty screen.

Phase 6

Talent

engine built

Reviews with company values, comp cycles, internal job postings, talent marketplace.

Status, plainly. Phase 0 is complete and tested. The engines for leave, overtime and performance are built and unit-tested but not yet wired to screens. The India pack has its structure and refuses live payroll until its statutory rates are verified — that refusal is deliberate.