The organizational graph

The graph is what Memnox knows. Everything else, the review queue, the reports, the incident that opens on its own, is a view over it.

It is deliberately small. A graph that models everything models nothing, so Memnox holds six kinds of node and six kinds of tie, and each one earns its place by being something a decision might depend on.

A decision in the middle, the five other node kinds around it, and one tie lighting up at a time. Every node also carries the URL it came from, which is the edge you follow when you disagree with what Memnox believes.

The nodes

Kind

decision

Something the organization decided, now binding

person

A human, and every account known to be theirs

system

A service, repository, path or environment a decision constrains

agent

An AI agent registered against the runtime

incident

Something that went wrong, or nearly did

source_event

The Slack thread, pull request or meeting note behind a node

Every node carries a sourceRef, the URL it came from. A node with nowhere to point back to is not stored. See Source events and evidence.

The ties

Relation

affects

This decision constrains that system or path

owns

This person owns that decision

caused_by

This incident was caused by that agent

touched

This incident reached that system

supersedes

This decision replaces an earlier one

evidenced_by

This decision was extracted from that source event

supersedes is the one people underestimate. An organization does not delete decisions; it changes its mind. Keeping the old node and pointing the new one at it is what lets you answer "when did we stop doing it the other way, and who decided?", which is the question that actually gets asked.

Console → Graph, with one decision node selected and its neighbours expanded

screenshot slot, save as public/screens/…png and set src

Selecting a node shows its ties in both directions. The evidence edge is the one to follow when you disagree with what Memnox thinks was decided.

Reading it

Three questions cover most use:

What does this decision constrain? Follow affects outward. This is the question a policy author asks before writing a rule that overlaps an existing one.

Why do we do it this way? Follow evidenced_by to the source event and read the original thread. Nobody has to remember; the link is the memory.

What did this agent touch? Follow caused_by inward from an incident. This is the first move in incident response.

Scope

A graph is built for a workspace, but it may span more than one. A project that covers a frontend and a backend in separate workspaces produces one graph across both, because a decision about the product does not stop at a repository boundary.

The graph records both the workspace you asked about and every workspace it was actually built from, so a graph that reached wider than you expected says so rather than looking like one workspace's answer. See Orgs, workspaces, projects.

People are resolved, never assumed

A person node is one human with several accounts attached, a Slack member id, a GitHub login, a Jira account. Email is the only evidence strong enough to merge on, and everything else is a candidate until it matches one.

This matters far more than it looks. Author trust at ingestion is a lookup against these people: an event whose author resolves to a known person in the workspace is trusted, and an unrecognised or absent author is tainted. Getting identity wrong therefore does not produce a cosmetic bug, it produces a wrong trust decision.

See People.

Node ids are stable

A node id is kind:normalized-key, so decision:no-pii-in-logs. The same decision keeps the same id across rebuilds, which is what makes a link to it worth pasting into a ticket.

Decisions and memory

How a conversation becomes a node in this graph.

Source events and evidence

What has to be true before anything is stored at all.