Headcount is not an opinion. Declare the person once.
An employee is a fragment in six systems that disagree about the start date. Join them by declaration, and route consequential changes through review.
The systems you already run, the objects your product declares, and the work your team gets back.
These marks name the kinds of system a source declaration reaches — a picture of the ecosystem, not a fixed menu, and nothing here implies a partnership.
Fewer exports to reconcile. More time with people.
One person, six systems
Declare the person once and the HRIS, payroll, identity and asset records stop keeping separate start dates.
Sensitivity by declaration
Who may see salary is declared on the object, not remembered by whoever shares the spreadsheet.
Changes with an approver
A promotion crosses an Action that a second person approves, so the record shows who changed what.
What teams build. On day one.
Four places this work turns into declared objects, governed reads, and reviewed changes.
Headcount that agrees
Define headcount once as a Function and it returns the number with the records behind it, at a stated version.
Joiner readiness
From accepted offer to first day, a Workflow waits on the contract, fires the provisioning Actions IT declared, and reports what is still open.
Case handling
Employee-relations matters become objects only their handlers can discover, with documents attached as immutable versions and each status change recorded.
Leaver checklist
Access revoked, laptop returned, final payroll confirmed: one Workflow across systems that do not talk, where a failed step stays open.
How it runs. End to end.
The same path every product takes: connect what exists, declare what it means, then publish the reads and the changes.
- 01
Connect the systems that hold employment data
Nothing here writes back into the HRIS, payroll or the identity provider. Bijection takes a dated copy on a schedule you choose, and every answer says which copy it read, so last week’s headcount can be reproduced instead of argued about.
- 02
Declare the person, and who may see what
Model employee, position and team and the links between them, then declare which properties each role can discover. Visibility is reviewed product source, not a toggle on a report.
- 03
Route the consequential changes through review
Compensation, level and employment status become Actions with declared effects. Review holds the change until a different person has approved exactly what it will do.
- 04
Automate the sequence, not the judgement
Onboarding and offboarding become Workflows that wait, resume and report. The decisions inside them stay with the people accountable for them.
Common questions.
No. It goes on owning the employment data it owns. What Bijection adds is the join: it reads the HRIS beside payroll, access and asset records and declares how one person links across them, so a question touching all four stops being four exports matched by hand.
Visibility is declared once on the object and enforced in every read path, so a property a person cannot see does not appear redacted, it does not appear at all. That mechanism is only as correct as the declaration behind it, which is why the declaration lives in reviewed source and not in a settings screen.
No, and we would not claim it. It gives you mechanisms a compliance programme needs: declared visibility, reviewed changes, an append-only record of who changed what, and evidence you can export. What your obligations are, and whether you meet them, remains yours to establish with your own advisers.
Bring us a process.
We'll build it with you.
A business process, the systems it touches, and the rules it needs to follow.