Documentation embedded in this build.

Can they?

Every door in this deployment answers the same question when somebody arrives at it: may this person do this, right now? The question pages let you ask it before a door has to — about yourself, and, where your deployment lets you, about somebody else.

They are at can.<your-deployment>, and at /can under your own door's name. Nothing on them grants anything, changes anything, or is recorded as a decision. They are the engine that enforces your deployment answering a question nobody is actually asking it yet.

Why ask before the door does

A refusal at a door is a true answer and a poor explanation. It arrives when somebody is trying to work, it says as little as it safely can, and it tells you nothing about what would have worked instead. These pages are the other side of that: the same engine, the same clauses, the same order, asked deliberately and read at leisure.

Three things make it worth asking:

• The verdict is the real one. It comes from the evaluator that decides live requests, over the specification your deployment actually enforces and the dataset it actually holds. It is not a simulation and it is not a second copy of your policy.
• The reasons are in the order a door checks them. An answer is a verdict and then the clauses behind it, numbered — so the first line is the one enforcement itself would report and the rest are what you will meet after fixing it.
• Nothing is saved. A question is not a policy. What you get instead is a link: the whole question is in the page's address, so "look at this" is something you can hand a colleague.

The three questions, and the grid

• Can I? Everything about you. Which missions you hold and through what, whether you are in good standing, whether you are cleared for a marking, whether you would pass one operation or one door's route — and, if not, which clause stopped you. Every person may ask this, because the subject is themselves.
• Can they? The same question about somebody else. The people you can ask about are the members of the projects you look after; asking is delegated and audited (below).
• Who can? The question turned around: everybody who satisfies one operation. Your deployment answers this only for somebody who may see every name in the answer — in practice the operators — so the page asks, and prints what it is told, refusal included.
• The matrix. Up to eight subjects across, up to eight policies or markings down, one verdict per cell. It is asked as one question, so every square describes the same moment rather than eight moments a few seconds apart, and every cell is a link to that pair's whole answer. This is where why can Alice reach the records door but not the feed stops being a dozen page loads and becomes a picture.

Pick what to ask from the list of everything your deployment enforces: what an operation declares, what a front door's route requires, what a mission restricts, what an obligation asks of a population. Or write a requirement yourself — a mission, a group, attribute clauses — in the same grammar a specification uses. Your deployment parses what you write with the parser it loads a specification with, and refuses a clause that would not load, in its own words.

The list carries a customer's own operations too, where your deployment declares one of their documents as an authorization map of its own (dialects): those rows are named by the service they sit on rather than by a door this deployment runs, because it enforces their requirement and serves their address nowhere.

Supposing things: the as if panel

Three things can be supposed, and the answer is about the deployment as you described it:

• as if also a member of a group the subject is not in yet — which is the question you are really asking when somebody needs access: would putting them on that desk be enough?
• under one mission alone, instead of everything the subject holds. A door weighs all of it; naming one asks the narrower question, would this alone be enough?
• through a chain of doors the request would pass, by distinguished name. Every clause has to hold at every hop, so a chain can only ever narrow an answer — and a clause a hop fails is reported as one, naming the hop.

Every supposition you set is printed on the answer as its own labeled line, above the verdict, exactly as your deployment echoed it back. That is deliberate and it is not decoration: a screenshot of one of these pages must not be readable as a decision, and the labeled line is what stops it being one.

What an answer withholds, and why

An answer tells you only what you could already learn elsewhere on this deployment. That rule is applied by the deployment itself, not by the page — the page has no filter of its own, and renders what it was given.

In practice:

• A subject you may not see is answered no such subject, in the same words an absent one is. Those two answers are identical on purpose: a different wording for "exists but not for you" would tell you the record is there.
• A requirement you may not see — a mission, a group, an attribute clause's values — arrives as a requirement you cannot see, with its position kept. So the order and the count of an answer stay honest while the name in it does not travel: you can see that the second clause is one you may not read, rather than concluding there were only two.
• A marking question gives you the verdict always, and the reason only where you may be told it. That is the same answer your deployment's clearance authority gives a caller who may not be told one — the two never disagree, one merely says less.
• The answer says when something was withheld, without saying what. A page that quietly showed a shorter requirement would be worse than one that says "part of this is withheld".

One consequence worth knowing: what you are told also depends on the door you asked through. Every clause has to hold at every hop, so an answer relayed through a service that carries no clearance of its own names nothing above the empty marking. If your question pages explain less than you expect, that is usually the answer.

Asking about somebody else is delegated, and audited

A question about another person cannot be posed by a bare certificate, whatever it holds. It has to arrive through a non-person entity — which is the rule that only a service may speak for somebody, read back to a question surface — and the person at the head of that chain has to hold the mission your deployment binds for it.

The question page is that service. When you ask about a colleague, the question travels with your name at the head of the chain and the door's at the tail, and your deployment records both, beside the subject you asked about. So:

• there is no hidden page and no hidden button: if your deployment has not admitted you, you meet its own refusal on the page, in its words;
• the people you can ask about are the ones your deployment's delegation reaches, which is why the picker is the members of your own projects and not a directory listing;
• somebody can always find out that you asked.

What these pages do not do

• They decide nothing. No door consults them; a door that did would be a door with two policy engines and one audit trail.
• They suppose no attributes. You can suppose a membership and nothing else. A finding about a missing clearance has to be about a record that really lacks one, or it is a sentence nobody can act on.
• They save nothing. Authoring a mission is the project workspace's job and authoring an operation's requirement is the specification's. A question you want to keep is a link.
• They enumerate nothing. Every list you pick from is your deployment's own, filtered before it reached the page, and the one question that walks the whole directory is the one your deployment gates most strictly.