The engine underneath every module
SOURCE · POWER · PATH
Three questions asked of every object in the system: where did this come from, who holds the leverage in it, and what happens next for the person in front of me. Each lens reads only what has been written down. When nothing has been written down, the answer is NO RECORD — refused, and that is a real answer, not an error state.
SOURCE
Where did this come from?
A tier from S1 to S6, an origin sentence, whether a human vouched for it, and how complete the record is. SOURCE never guesses a tier from how convincing something sounds.
States: verified · contested · unsupported · not stated
POWER
Who holds the leverage?
Creator share, who controls access, whether there is an audit right, the term, the cost of leaving, and downstream use. Severity is the maximum across components, never the average — one unacceptable term is not softened by five fine ones.
Rooms never carry POWER. A room is people, not a deal.
PATH
What happens next for me?
The next action, the window in days, whether the step is reversible, and what it forecloses. Forecast fields are labelled as forecasts; the engine reports the recorded window rather than inventing a new one.
A missing next action is refused, not filled in with "review".
The refusal principle
An empty field means nobody read it. It does not mean zero.
This is the rule the whole engine turns on. A blank creator-share is not a 0% share — it means nobody has read the contract. A blank next action is not "nothing to do" — it means nobody has decided. The engine keeps the two apart everywhere, including in the database, where the generated columns preserve NULL rather than coalescing it to zero.
NULL versus zero — a live demonstration
Why it matters here
In an investigation the difference is the whole job. "The marina holds no gate logs for that date" is a finding. "Nobody has asked the marina for gate logs" is an open task that looks exactly like a finding on a dashboard that coalesces NULL to zero.
One of those gets written into a report. The other gets someone's case dismissed.
Working query box
Ask it something
Type a question and pick an object. The router shows which specialty lens matched and why, then runs it. The exact parameterised query fragment is printed underneath, because "show me the query you ran" is the only way to trust an answer you did not compute yourself.
The nine specialty lenses
| Lens | Question | Reads |
|---|
Where no keyword matches, the router says so and refuses to pick one at random. A confident wrong lens is worse than an honest shrug.
Binding
Which object types carry which lenses
Binding is fixed in the schema, not decided per screen. The two rules that matter: rooms never carry POWER, and person-records are rooms.
| Object type | SOURCE | POWER | PATH | Room? | Note |
|---|
Specialty triads
| ID | Rule |
|---|
Interpretation notice
The Triple Lens as described here is the owner's engine, reproduced as faithfully as this prototype can from the specification supplied.
The EXODUS / CONDUIT / HALO module names, and their scope, are this build's interpretation and are awaiting the owner's confirmation. They are labelled that way on every page where they appear.