A request-time authorization rule permits reading an animal's precise collar coordinates only after its embargo date passes — which inputs does the evaluator need?

juniorshould knowfreq 52%

answer

who, what, which action, and when
four groups of named values
the record carries its own embargo date
the clock is an input too
most rules read two groups

basics

~20 s

Four groups of named values: the subject (who is asking, and their affiliations), the resource (the animal record, including its embargo date), the action (read precise coordinates), and the environment (the current instant). Most rules read two of the four.

solid answer

~40 s

An attribute rule is an expression over named values grouped by what they describe. Subject attributes describe the caller — identity, affiliations, roles, entitlements. Resource attributes describe the thing acted on — this animal's species, study area, embargoUntil date and critical flag. The action names what was asked, so read-coarse-cell and read-precise-fix are separable questions over one record. Environment attributes describe the circumstances and belong to neither party: the current instant above all. The embargo clause compares a resource attribute against an environment attribute, so the answer changes without any write happening. Nothing in that clause is a property of the caller, which is why a table of per-person grants has nowhere to store it.

An attribute rule is an expression over named values grouped by what they describe. **Subject** attributes describe the caller — identity, affiliations, `roles`, `entitlements`. **Resource** attributes describe the thing acted on — this animal's species, study area, `embargoUntil` date and critical flag. The **action** names what was asked, so `read-coarse-cell` and `read-precise-fix` are separable questions over one record. **Environment** attributes describe the circumstances and belong to neither party: the current instant above all. The embargo clause compares a resource attribute against an environment attribute, so the answer changes without any write happening. Nothing in that clause is a property of the caller, which is why a table of per-person grants has nowhere to store it.

code

json · 20 lines

json

{
  "subject": {
    "sub": "u-8814",
    "affiliations": ["study-area-north-rift"],
    "roles": ["researcher"]
  },
  "action": "read-precise-fix",
  "resource": {
    "type": "animal",
    "id": "a-2291",
    "species": "panthera-pardus",
    "studyArea": "study-area-north-rift",
    "embargoUntil": "2026-11-01T00:00:00Z",
    "conservationStatus": "vulnerable"
  },
  "environment": {
    "now": "2026-09-19T14:03:11Z",
    "season": "2026-dry"
  }
}

go deeper

for a junior

Be able to name the four groups and sort three or four concrete values into them without hesitating. Knowing that the animal's embargo date is a resource attribute and the current time an environment attribute is most of the answer at this level.

for a middle

Explain why the action must be a named input rather than implied, and why the embargo clause makes the answer change with no write. Show that you would design the attribute vocabulary — names, types, units — before writing a single rule.

for a senior

Show the operational consequence: every guarded request now loads the record before deciding, so the decision sits on the hot path. Say which attributes the rules in force actually reference and why you assemble those and no more.

for a principal

Argue whether the vocabulary can express next year's rule without a redeploy. Attributes named after conclusions rather than facts are the trap; they push rule changes back into the services that compute them, which is exactly what this design was meant to avoid.

The rule a grant table has nowhere to put

A wildlife-tracking service stores collar fixes for individual animals. Anyone signed in may see a coarse 10-kilometre cell; the precise coordinates are poaching-sensitive. The biologists' rule reads: a researcher may read precise collar coordinates only after the embargo on that animal has lapsed, only inside a study area they are affiliated with, and never for a species flagged critical this season.

Only one of those three clauses is about the caller. Two are about the animal record, and one turns on the moment the request arrives. A store that holds rows of the form "this person holds this permission" has nowhere to keep an embargo date, so the decision moves to a rule evaluated on every request over attributes — named values describing the parties and the circumstances, compared by an expression that returns allow or deny.

The four groups of input

group	what it describes	in this service
subject	the principal making the request	the researcher's identity, their study-area affiliations, their `roles` or `entitlements`
resource	the thing being acted on	the animal record: species, study area, `embargoUntil`, the critical flag
action	what was asked of it	`read-coarse-cell`, `read-precise-fix`, `export-track`
environment	circumstances belonging to neither party	the current instant, the season, the source network

Three consequences follow at once:

The resource is an input, not a lookup key. The rule does not ask "may this person read animals"; it asks a question about this animal, whose own fields decide it.
The action must be named explicitly, because one record supports several distinct requests and the rule has to tell them apart. A 10-kilometre cell and a six-decimal fix are different questions over the same row.
The environment carries a clock. A rule containing "after the embargo date" flips its answer with no write anywhere in the system — the property that makes such a decision awkward to cache and easy to mis-test against a frozen clock.

Which of the four a rule genuinely needs

Most rules read two groups, not four. Populating the unused ones anyway is how an attribute vocabulary quietly becomes a place where anything can be stuffed. Walk the three clauses:

"only after the embargo on that animal has lapsed" — resource (embargoUntil) compared against environment (now).
"only inside a study area they are affiliated with" — subject (affiliations) compared against resource (the animal's study area).
"never at all for a species flagged critical this season" — resource (the flag) against action (read-precise-fix); the subject does not appear at all.

Clause 3 is the one worth staring at. It denies everybody, regardless of who they are, and no amount of per-person granting expresses it. Clause 1 is the one that makes the answer time-dependent. Only clause 2 mentions the caller, which is the ordinary case people picture when they imagine an authorization check.

The vocabulary is a contract before it is a rule

Before any rule is written, the attribute names, types and units are a contract between the code that assembles the input and whoever writes the rules. embargoUntil as an instant in UTC is a different attribute from embargoed as a boolean somebody computed earlier, and a rule written against the second cannot be changed without redeploying the service that computes it. Three habits keep the vocabulary usable:

Name an attribute after the fact, not the conclusion: speciesConservationStatus, never isForbidden.
Keep one canonical type and unit per name across every service that assembles an input.
Record which group each attribute belongs to, because the group decides where the value may legitimately come from and how fresh it has to be.

What it buys and what it bills

The rule can now change — an embargo shortened, a species newly flagged — without a schema change and without reissuing anything to anyone. The bill lands on the request path: every guarded request must assemble a complete input, which means loading the animal record before the decision rather than after it, reading a clock, and knowing which of the caller's attributes are trustworthy at all. That is the work this design moves onto the server author, and it is why the follow-up question is always "and where do those values come from?"

## The rule a grant table has nowhere to put A wildlife-tracking service stores collar fixes for individual animals. Anyone signed in may see a coarse 10-kilometre cell; the precise coordinates are poaching-sensitive. The biologists' rule reads: *a researcher may read precise collar coordinates only after the embargo on that animal has lapsed, only inside a study area they are affiliated with, and never for a species flagged critical this season.* Only one of those three clauses is about the caller. Two are about the **animal record**, and one turns on **the moment the request arrives**. A store that holds rows of the form "this person holds this permission" has nowhere to keep an embargo date, so the decision moves to a rule evaluated on every request over **attributes** — named values describing the parties and the circumstances, compared by an expression that returns allow or deny. ## The four groups of input | group | what it describes | in this service | |---|---|---| | **subject** | the principal making the request | the researcher's identity, their study-area affiliations, their `roles` or `entitlements` | | **resource** | the thing being acted on | the animal record: species, study area, `embargoUntil`, the critical flag | | **action** | what was asked of it | `read-coarse-cell`, `read-precise-fix`, `export-track` | | **environment** | circumstances belonging to neither party | the current instant, the season, the source network | Three consequences follow at once: - The **resource** is an input, not a lookup key. The rule does not ask "may this person read animals"; it asks a question about *this* animal, whose own fields decide it. - The **action** must be named explicitly, because one record supports several distinct requests and the rule has to tell them apart. A 10-kilometre cell and a six-decimal fix are different questions over the same row. - The **environment** carries a clock. A rule containing "after the embargo date" flips its answer with no write anywhere in the system — the property that makes such a decision awkward to cache and easy to mis-test against a frozen clock. ## Which of the four a rule genuinely needs Most rules read two groups, not four. Populating the unused ones anyway is how an attribute vocabulary quietly becomes a place where anything can be stuffed. Walk the three clauses: 1. *"only after the embargo on that animal has lapsed"* — resource (`embargoUntil`) compared against environment (now). 2. *"only inside a study area they are affiliated with"* — subject (affiliations) compared against resource (the animal's study area). 3. *"never at all for a species flagged critical this season"* — resource (the flag) against action (`read-precise-fix`); the subject does not appear at all. Clause 3 is the one worth staring at. It denies everybody, regardless of who they are, and no amount of per-person granting expresses it. Clause 1 is the one that makes the answer time-dependent. Only clause 2 mentions the caller, which is the ordinary case people picture when they imagine an authorization check. ## The vocabulary is a contract before it is a rule Before any rule is written, the attribute **names, types and units** are a contract between the code that assembles the input and whoever writes the rules. `embargoUntil` as an instant in UTC is a different attribute from `embargoed` as a boolean somebody computed earlier, and a rule written against the second cannot be changed without redeploying the service that computes it. Three habits keep the vocabulary usable: - Name an attribute after the **fact**, not the conclusion: `speciesConservationStatus`, never `isForbidden`. - Keep one canonical type and unit per name across every service that assembles an input. - Record which group each attribute belongs to, because the group decides where the value may legitimately come from and how fresh it has to be. ## What it buys and what it bills The rule can now change — an embargo shortened, a species newly flagged — without a schema change and without reissuing anything to anyone. The bill lands on the request path: every guarded request must assemble a complete input, which means loading the animal record **before** the decision rather than after it, reading a clock, and knowing which of the caller's attributes are trustworthy at all. That is the work this design moves onto the server author, and it is why the follow-up question is always "and where do those values come from?"

Where does a caller's role fit in this model?
A role is a subject attribute like any other — one named value the rule may read, alongside affiliations and identity. The difference from a grant-table design is that the role stops being the whole decision and becomes one term in an expression that also reads the record and the clock. A rule may ignore it entirely, as the critical-species clause does.
Does every rule have to read all four groups?
No, and forcing it to is a smell. Most rules read two: subject against resource, or resource against environment. Assembling values the rule never reads costs a lookup per request and makes the input a dumping ground. Assemble what the rules in force actually reference, and revisit that set when the rules change.
What makes the embargo clause different from the other two at run time?
It is time-dependent, so the answer changes with no write to any record. Nobody edits the animal, nobody edits the researcher, and at midnight the decision flips. That has two consequences: a test must control the clock rather than assume it, and a stored copy of a previous answer must not outlive the instant the rule turns on.

A ticketed evening event. The ticket names you (subject), the seat it admits you to (resource), whether it is a standing or a seated ticket (action), and the doors open at eight (environment). The door staff compare all four; a ticket alone settles none of it.

saying these in an interview costs you the question

Says an attribute rule only looks at the caller's roles.
Treats the embargo date as a property of the researcher.
Assumes every rule must populate all four input groups.
Calls the current instant a subject attribute.
Leaves the requested action implied rather than naming it.
Thinks the resource is only a key, not a set of inputs.

A request-time authorization rule permits reading an animal's precise collar coordinates only after its embargo date passes — which inputs does the evaluator need?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The rule a grant table has nowhere to put

The four groups of input

Which of the four a rule genuinely needs

The vocabulary is a contract before it is a rule

What it buys and what it bills

▾common follow-ups3 questions

▾analogy~20 s

▾red flags6 flags

The rule a grant table has nowhere to put

The four groups of input

Which of the four a rule genuinely needs

The vocabulary is a contract before it is a rule

What it buys and what it bills

answer

go deeper