MARRINN

Simple · Powerful

Marrinn · The architecture · The Core

The Core.

Every module on one data model. One permission matrix across 235 actions, one audit trail, and every module reading the same records — so there is no integration between finance and HR to maintain, because there was never a seam.

One data modelEvery module reads the same records
235 actionsOne role by action matrix, editable
One audit trailActor, target, old and new values
Written from your specThe meaning is already the model
01A worked example

One leaver, and seven systems that never hear about it.

Nobody buys a platform to handle a resignation. But offboarding is the cleanest test of whether a company runs one system or seven, because it is the moment every system has to agree about one person on one day — and the failure is never the six you remembered.

The version below is ordinary. A mid-size company, a two-week notice period, and four departments who each hold part of the same person.

Worked example · Offboarding

The leaver whose licence you pay for until the audit.

On separate products this is four tickets, four owners and four chances to miss one. The cost of the one you miss is not the ticket. It is a live account, an open approval, or a renewal invoice nobody can explain.

What four departments each hold
  • HRFinal salary, leave balance, gratuityA profile, a leave record and an end-of-service calculation.
  • FinanceAn expense claim still openUnreconciled, and a corporate card nobody has cancelled.
  • ITA laptop, four accounts, two licencesAssets to return, access to revoke, seats you keep paying for.
  • DeliveryTwelve work items and four approvalsWork assigned to someone who left, and approvals waiting on them.
What one data model resolves

One person, in one place

These are not four systems that have been integrated. They are modules reading the same records, so the leaver is one person rather than four rows that resemble each other. What they hold, what they own and what is waiting on them is a question with an answer, asked once, rather than four enquiries and a spreadsheet to reconcile them.

The permission matrix is the same matrix. Access is not revoked in four places, because it was never granted in four places. One role by action matrix across roughly 235 actions decides what a person can reach, and every change to it is written to the audit log.

The renewal invoice you cannot explain

A software seat assigned to somebody who left in March is discovered in November, by finance, on a renewal. When the asset register and the person record are the same record, the seat is visible the day the person is marked a leaver.

The approval waiting on nobody

A state transition sitting in a departed member’s queue does not announce itself. It looks exactly like an approval somebody is thinking about, until a delivery date slips and someone goes looking.

The audit question with one answer

Who changed this, when, and what was it before? The audit log records the actor, the target, the old and new values, and the request it came from. It is append-only and exports to CSV for whoever is asking.

No seam to maintain

An integration between finance and HR is a thing that has an owner, a cost and an outage. There is nothing to maintain here because the two were never separate products with a pipe between them.

02How it holds

Governance you can read, in a table.

Most platforms describe their permissions in a support article. Here the permissions are a grid: every action in the product against every role, allowed or denied, on screen and editable. If you cannot see your own governance you cannot audit it, and you certainly cannot prove it to anybody else.

Matrix

Roughly 235 actions, by role

Every action has a stable key in the form resource then verb — create an item, close a sprint, change a member’s role, edit an approval policy. A cell answers one question: is this allowed for this role?

Exceptions

Overrides that win

Five roles set the default, and overrides layer on top for a member, a project or a team. An access test tells you the computed answer for a real person, so you are not reasoning about it in your head.

Danger

Risk-tagged actions

Destructive and security-sensitive actions carry a risk tag in the matrix — deleting a project, changing a role, editing a policy, purging audit data. A dangerous grant is visible at a glance rather than buried in a list.

Record

Append-only

Role changes, permission changes, approval and SLA policy edits and archives are recorded with the actor, the target, the before and after, and the originating request. Events cannot be edited after the fact.

Scope

A feed per project

A project lead can see what happened in their project today — work-item activity merged with the audit events scoped to that project — without being given the whole workspace audit log.

Retention

Export, then purge

Audit data grows forever unless somebody manages it. Export the filtered slice to CSV for the archive, then purge older events on a retention schedule so the live log stays fast.

03The other six

Seven parts, one operating system.

Read the seven from the bottom and it is an operating system: a kernel, a data model, memory, a way to see, processes that do work, a place those processes meet people, and ports to everything outside.

The Core is one of seven parts.

It sits above the kernel and below the memory: the kernel is the model you choose, the core is every module on one data model, The Memory is what they all agree on, and the ports are how it reaches the software you already run.

See all seven parts → Book a demo