How a decision is made

Everything Memnox does reduces to one question, asked at the moment an action is about to happen: should this, by this agent, at this moment, proceed.

Every action passes the same five stages, in the same order, every time. There is no LLM in this path: same input, same answer, always.

That is not a performance choice. Security decisions need guarantees rather than probabilities, and a verdict you cannot reproduce is a verdict you cannot defend six months later.

The three effects

There are three, and there are no others. Two would make a governed system a wall, and a fourth would put authority somewhere nobody can audit.

1. Resolve

A command line becomes one action name. gh pr merge 12 becomes gh.pr-merge, psql -c "DROP TABLE users" becomes psql.drop, and git push --force becomes git.push-force, which is deliberately a different action from git.push.

One function does this, and every surface calls it: the scan, explain, protect, policy test, the governed shell and the interceptors. Two resolvers would mean a rule written from one screen silently failing at another.

2. Rules

Every rule that matches is collected, and the most restrictive effect wins:

deny  >  ask  >  allow

Order in the file does not matter, and the most specific rule wins.

A rule matches on the action, the target, the environment, the branch, the working directory, how the request sat against the scope the session declared, which state facts are in force, and, locally only, the call's own arguments. See Writing policies.

3. State

A rule can apply only while something is true right now.

[policies.match]
actions = [ "railway.up", "vercel.deploy-prod" ]
state = [ "freeze:payments" ]

memnox freeze payments --for 2h declares that fact, every surface sees it on the next command, and it lifts itself when the window ends. The facts are handed to the gate rather than queried by it, so a freeze costs nothing to check.

Every fact carries a mandatory expiry. A freeze that outlived its incident would be worse than no freeze, because the next one gets ignored.

4. Hold

ask holds the call and asks a person. The prompt names what produced the verdict: the state fact, the rule, and the repository evidence already on disk.

[Memnox] cursor wants to run: railway volume delete pg-prod
 
  DENIED  no volume deletes while payments is frozen
 
    state  freeze:payments — troubleshooting (1h 56m left, moise)
    rule   railway-destructive
 
  [a] allow once   [s] allow for this session   [e] edit it   [d] deny

A refusal that explains nothing gets the gate removed; one that shows the freeze somebody declared four minutes ago ends the argument instead of starting it. [e] fixes a wrong flag without killing the agent's loop, and the edited command goes back through the rules from the start, because otherwise [e] would be the way around all of them.

A hold is written to disk, so something other than the terminal it started in can answer it. See Approvals.

5. Record

Every decision appends exactly one row to an append-only ledger: who, what, the effect, the reason, the rule, the exit code and the duration. Every row also records the content hash of the rule set that decided it, so a verdict traces back to the rules in force at that moment rather than the ones in force now.

memnox why            # the last thing that did not simply proceed
memnox trace <id>     # one action end to end
memnox timeline       # all of it, in order

See Activity and audit for the chain itself and how to export it.

Determinism, and time

Rules can carry time windows, and state facts expire. That would normally break reproducibility, so the moment is passed into evaluation rather than read from a clock inside the engine.

Replaying a recorded action with its own timestamp reproduces the same verdict. That is what makes memnox why an answer about what was decided rather than a guess about what would be decided now, and what lets memnox check be trusted before anything runs.

Three layers, and none speaks for another

1. 1

   The runtime decides whether a rule forbids it

   Deterministic, on one machine, with no account and no network. Its refusal is final and nothing above widens it, and it keeps deciding when the cloud cannot be reached, on the rules already on the disk.

2. 2

   The team decides who could authorize it

   From verified authority, at the size the action actually is. This needs more than one person to mean anything, which is why it is the hosted half.

3. 3

   The clearance decides how much of the answer you are told

   Filtered to what this person is entitled to know.

This is why an action can be allowed by every rule and still be held. No policy file knows that the orders database is the platform team's to answer for; the team does. A rule names a role rather than a person for the same reason: a rule naming a person is wrong the week they change jobs.

Where the LLM actually lives

Nowhere in the runtime. Not in discovery, not in classification, not in a verdict. The one place a model appears in the product at all is extraction, in the hosted half, turning conversations into candidate decisions for a person to approve. It writes nothing directly, and its output is a suggestion until somebody's name is attached.