One matrix decides
who owns every field.
Data integrity as architecture: per object and per property you declare the authority mode — authoritative, computed or manual — and a ranked source list per object type decides which connector wins. Turn enforcement on and connector-owned fields stop being hand-editable. The data model itself is open for your own object types — with governed processes on top of them, and rules that let a record's lifecycle drive an entitlement's.
Source of truth, explicit
No more "who changed this field?"
The matrix declares the authority mode per property; a ranked source list per object type decides which connector wins. Turn enforcement on and connector-owned fields can't be hand-edited into drift — conflicts resolve deterministically instead of by whoever saved last. Even the API is a modelled source: a scoped credential can push identities, and a collision with an HR-owned record is refused with the owning source named, not silently merged.
- Per-property authority mode: authoritative, computed or manual — overridable per identity type
- A ranked source list per object type settles which connector wins a field
- Enforcement is a switch: with it on, a write to a connector-owned field is refused
- HR stays authoritative for people — directory and IAM systems can't claim identity attributes
- Accounts stay owned by their target system; a source connector can never hold accounts
Model your own objects
Governance beyond people and accounts.
Define custom object types — external organisations, facilities, projects, whatever your governance needs — with ownership, context, validity and provisioning as first-class aspects. No per-type custom code: the same record UI, the same ownership cascade, the same review engine.
- Custom object types with ownership, context, validity and provisioning aspects
- Custom properties on every governed object kind and every type you define
- Org dimensions — department, cost centre, location, company, function — auto-created from HR
Record processes
Your business records get governance too.
A supplier gets created in a spreadsheet, mailed to Finance, retyped twice, and afterwards nobody can say who approved it. Declare a create, update or retire process on any object type you have modelled — a real form, a real approval chain — and that stops being true.
📝 A form the platform actually enforces
Text, dates, choices, and type-ahead pickers over your own identities and records. Validation is server-side and real — format, pattern, length, numeric and date ranges — each with a message you write yourself, so a rejection says something a business user can act on. A field can appear based on an earlier answer.
✅ The same approval chain as everything else
Pick a pre-configured reviewer chain — the same named chains that route your access reviews and access requests — or compose one inline. Multi-step and quorum apply unchanged. Auto-approval exists and is an explicit step in the chain, so a process that approves itself says so where you read it.
🤝 Two people, one record
Some records genuinely can't be described by one person. A create process can ask the requester for their half — who the supplier is, which department sponsors them — and route the rest to Finance for the VAT and banking details. One record, one approval, two contributors. Update and retire stay single-submitter, and the builder says so rather than offering a path it can't finish.
🗄️ Retire means archive, not delete
A retired record stays readable and keeps its history — the reviewer's task says exactly that before they approve it. And the approver sees the labels the requester saw, frozen at submission: rename a field afterwards and the approval still shows what was actually asked.
Lifecycle coupling
Joiners and leavers, one level up.
Onboard a supplier and somebody eventually creates a group for them. Retire a cost centre and that group outlives it by years — noticed by an auditor, not by anyone who could have prevented it. A coupling rule writes that connection down: the business object model drives access governance directly, instead of depending on somebody remembering.
🌱 A new record proposes access — it never creates it
When a record starts matching your rule, the coupling drafts a governed access request with the name, purpose and owner already derived from the record. It stops there. The entitlement exists only after a person completes that draft and it travels its normal approval chain — the same reviewers and the same evidence as one somebody typed by hand.
🌙 A retired record proposes an end, and waits
Archive the record and the coupling proposes a deprecation plan against the linked entitlement — proposed, not executed. Nothing is revoked, disabled or deleted until a human approves it, and only then does the sunset clock start. Cancel it once and the rule never asks again: an automation that re-asks a question you already answered is noise, not a control.
🛑 A brake, because bulk changes look like reorganisations
If one pass would propose deprecating ten or more entitlements and that's more than a quarter of everything the rule holds, it proposes nothing at all and raises a warning instead. A half-finished import and a genuine reorganisation look identical to a rule — and the difference matters far too much to guess. The brake fails toward keeping access.
A reorg rewrote 18 auto-grant policies. The migration printed every person who would gain access, per rule, and refused the one rule that was a different decision in disguise.
🔍 Nothing is seeded, and you can dry-run it
There are no default rules, because no default could be right for two organisations at once — nothing fires until you write one. Every rule has a dry run that writes nothing: which records match, what each proposal would be named, whose ownership would be derived, and whether the brake would trip.
See your data model governed on your own data.
A 30-minute kickoff connects your HR feed and one system — working POC the same day.
Bring your HR feed plus one system you trust us to read — that is all the kickoff needs. No NDA, no second call with a sales engineer, no procurement form.