DocsCore conceptsOrganizational state

Organizational state

Memnox holds statements about how the company works: what it decided, what it requires, who may authorize what, who owns what, and how people stand to each other. Every one of those statements is a fact, and every fact carries where it came from and whether anybody has confirmed it.

That second part is the whole design. A model reading a conversation must not be able to make something company policy.

A fact travels a path

Raw signal
Candidate
Verified
Superseded

Only a verified fact is ever used to authorize, route or answer. A candidate is a belief, and a belief authorizes nothing.

Provenance decides whether a human is needed

Provenance

observed

Read out of a conversation, a document or a meeting. Always a candidate.

declared

A person wrote it into Memnox. Verified by the act of writing it.

authoritative

A system of record said so: an IAM group, an HR role, CODEOWNERS, a project lead field. Verified, because the record is the thing itself.

The distinction is not about accuracy. An IAM group membership is not evidence that somebody is in a group, it is the membership, so there is nothing for a person to confirm. A sentence in a channel is a reading of something somebody said, and that is exactly the case a person should look at.

The five kinds

Kind

decision

Something the company chose. "EU payments go through Stripe."

policy

A rule work is held to. "Production deploys need two approvals."

authority

Who may authorize what, up to what. The basis of every approval route.

responsibility

Who owns a thing. The basis of every delegation.

relationship

How two parties stand to each other: reports to, belongs to.

Authority is a capability and a ceiling

An authority fact names a person, an action, and how far they may take it.

json
{
  "kind": "authority",
  "statement": "The Finance Manager approves refunds up to 5000",
  "subject": "payments",
  "principal": "manager@acme.test",
  "capability": "payment.refund",
  "limit": 5000
}

A capability matches a family, so payment and payment.* both cover payment.refund. A bare * matches nothing, deliberately: an authority that silently granted everything is the failure this shape exists to prevent. An absent limit is unlimited for that capability alone, never for others.

When more than one person could authorize an action, the tightest ceiling that still covers it is named first. Sending every small approval to the highest authority in the company is how approval becomes a rubber stamp.

Reading the systems of record

A record source answers one question: what do I currently assert. It never writes, and the sync decides what is new, what changed and what has gone.

Three rules hold, and each is a bug somebody has shipped elsewhere:

Rule

Idempotent

A claim is identified by its source key, so the sweep can run nightly without writing a new copy of the org chart every night

A change supersedes

An approval ceiling moving from 5000 to 10000 is two facts with dates, not one field overwritten

A failure retires nothing

An IAM outage must not read as the whole company losing its authority. The failure is reported and the existing facts stand

The directory source is the honest floor: who is a member, what department they are in, which teams they belong to. All of it is somebody's deliberate administrative act, which is what makes it authoritative rather than observed.

Note what it does not assert. No authority is minted from a role. Being an admin of the control plane is not evidence that somebody may approve a refund, and inventing that mapping is the failure this whole model exists to prevent.

POST/v1/workspaces/:ws/organization/syncadmin

Re-read every system of record. Idempotent, and safe to run on a schedule

Nothing is edited, only superseded

Changing a fact writes a new one and marks the old one superseded, with the link between them kept in both directions. The earlier statement keeps its own dates, so "what was our policy in March" stays answerable.

This is what turns a knowledge base into a record. Asking why the company does something returns the chain: the first statement, who confirmed it, what replaced it, and when.

GET/v1/workspaces/:ws/organization/factsviewer

What the organization states about itself, filterable by kind and status

POST/v1/workspaces/:ws/organization/factsreviewer

State a fact. Recorded as declared, which verifies itself

POST/v1/workspaces/:ws/organization/facts/:id/verifyreviewer

Confirm a candidate, which is the only way an observation becomes real

POST/v1/workspaces/:ws/organization/facts/:id/rejectreviewer

Say no. Kept, so the same reading is not raised forever

POST/v1/workspaces/:ws/organization/facts/:id/supersedereviewer

Replace a fact without losing the one it replaced

GET/v1/workspaces/:ws/organization/facts/:id/historyviewer

The version chain, oldest first. Why the company does this

There is no route that lets a caller claim authoritative provenance. That word means a system of record said so, and it is written by the connector that read the system, never by whoever is posting.

Next: Need to know, which decides who is told any of this, and Evaluate, which is where it is used.