Inside Perspectives

A Perspective is a typed record of what matters to someone, how those concerns are measured where they can be, and which limits and goals follow. It is a point of view, not evidence. Applying a Perspective changes which parts of a result are checked and how options are ranked. It never changes a run's output, and it never raises the grade the Epistemic Protocol Machine (EPM) gives a result. This reference describes the perspective model, its compiler, how Perspectives are applied to results and compared, and how people author, sign and share them.

A point of view, not evidence

A Perspective is optional. No inquiry, scenario, run, saved result, publication or share requires one. A person can use Whathappensify without ever creating a Perspective.

The EPM grades a result without reading any Perspective. What a Perspective records about a result travels beside it as a separate record. It never enters the result's evidence.

A Perspective can stop an operation it governs. A violated non-negotiable limit, or a question that needs people to decide, refuses that operation. That is the Perspective applying its own limits, not a judgment about the evidence.

A Perspective may also carry capability descriptors for particular operations. A descriptor that states any effect on a result's claim ceiling, and names no gate action, refuses the operation it names.

Three layers

Every Perspective has three layers. Two are authored; the compiler produces the third.

The authored value spaces and exchange contracts pass into the executable representation with the compiled limits and goals.

The meaning graph

Each claim is a subject, a predicate and an object. One example reads "the wheelchair user / must be able to cross / the one crossing they can use". A claim also records:

• who asserts it, and the community that backs it (its standing);
• where, when and in what situation it applies;
• its source, links to claims it disputes or refines, and attachments such as oral histories, photos or meeting notes.

Attachments stay with the claim and are never computed on.

Illocutionary force

Every claim carries one of eight forces. The force says what the claim does, and it decides what the compiler does when no mapping reaches the claim.

An assertion or a mandate carries enforcement. The compiler cannot guess how it should be computed, so it returns the question to people. A story or a question compiles with a note, because narrative and inquiry carry no enforcement.

Logic modality

A claim may also carry a logic modality, a second axis that varies independently of force. A mandate can be epistemic, and a story can be deontic.

The modality is recorded with the claim.

Operationalization status

A mapping that reaches a prohibited claim sends the Perspective to deliberation.

Sharing policy

Sharing policy governs computation, not disclosure. Anyone who can read the perspective can read the claim. Disclosure is set for the whole Perspective and the whole simulation, so a sovereign claim's text is shown with its Perspective.

The compiler stops a Perspective whose mapping reaches a sovereign claim. Readings hold the same line a second time: a limit serving a sovereign claim is skipped before its value is read.

An assertion or mandate that is sovereign or prohibited therefore always sends its Perspective to deliberation. With a mapping, the mapping is blocked. Without one, the claim lacks an operationalization.

Operationalization mappings

Each mapping ties one or more claims to one executable fragment: a limit, a goal or a capability gate. Each mapping carries its own version. A disputed translation can be contested without touching the claim or the computation.

A mapping that declares no loss is claiming that nothing was lost. That claim is open to inspection like any other.

How a mapping was made

Any method other than underdescribed must name an author and a time with a time zone. The platform refuses a mapping without them, so a contested translation can always be traced to whoever made it.

Where a mapping's review stands

The review status is recorded with the mapping, so a reader can see whether a translation has been reviewed or is disputed.

The executable representation

Limits

A limit names a measure, a comparison and a threshold, such as vehicles_per_hour <= 600. The comparisons are <=, <, >=, >, == and !=. A limit also names the value space it is measured in, a deontic operator and a tier. The comparison states the condition the result has to meet: a reading tests it exactly as written.

The model refuses three pairs: MUST with Aspirational, MUST_NOT with Aspirational, and MAY with NonNegotiable. An obligation cannot be optional, and a permission cannot be non-negotiable.

A Perspective can state a right as a non-negotiable limit. It names who asserts the right. The platform applies the limit within the Perspective; it does not establish that the right exists.

Goals

A goal names a measure, a direction (minimize or maximize), a value space and a weight above zero. Goals are where trade-offs happen.

Capability gates

A capability gate governs whether one of the ten operations may run under the Perspective.

A gate states its condition in words. A gate with no condition applies whenever the Perspective governs the operation. A refusal or deliberation notice from the gate quotes the condition.

Value spaces and scales

Every limit and goal refers to a value space: minutes, vehicles per hour, a count of people, a category of land use. Each value space declares its measurement scale.

Commensuration contracts

A commensuration contract authorizes combining two different value spaces. It names both spaces, the exchange rate, who authorized it, the community backing it, and, in words, the context it is meant for. The model refuses a contract from a value space to itself.

When a Perspective ranks options, each contract must give one positive rate. The contracts must connect the value space of every goal, and contradictory rates are refused. A goal measured in minutes is not combined with a goal measured in money unless someone states the rate on the record.

Compilation

Compiling a Perspective returns exactly one of two things. It returns the executable representation, or a deliberation result that states what the compiler declined to compute. The model refuses a compilation result that holds both, holds neither, or carries a success flag that disagrees with what it holds.

A successful compilation records which version of the compiler produced it and a digest of the measure vocabulary it used. The Perspective becomes compiled. A deliberation result makes the Perspective deliberation_required.

Refused before either outcome

Some faults mean there is nothing meaningful to compile. The compiler refuses the Perspective with an error naming the fault:

• a mapping names a claim the Perspective does not hold;
• a fragment is of an unknown type, or a limit lacks its identifier, value space, measure, comparison or threshold;
• a limit or goal refers to a measure outside the platform's vocabulary;
• goals sit in two or more value spaces and one of them is nominal.

Arithmetic across a nominal value space is refused whether or not a commensuration contract exists. Names support equality and membership, and nothing further.

Deliberation triggers

A deliberation result is a typed outcome, not a failure. For each trigger it lists the claims behind it and a question for people to settle. Every trigger except missing_commensuration also names the standing its claim records. It also lists the operations that remain available. That list holds all ten operations, less any the Perspective's gates deny, and less CHOOSE when a commensuration contract is missing.

Compilation warnings

Warnings accompany both outcomes.

An undeclared value space takes its scale from its name. Names containing severity, priority, level or risk become ordinal. Names containing temperature, celsius or fahrenheit become interval. All others become ratio.

Computation status

The same three values describe a deliberation result and every reading.

Readings

A reading applies a Perspective to a computed result. It records which limits the result meets, which it breaks, and what the Perspective could not evaluate. The result's output and grade stay as they were. A person can read their own result, or another person's published result, through a Perspective. The reading belongs to whoever made it. The worked example at the end of this section shows three readings of one result.

A Perspective chosen with a scenario proposal is recorded with it. Before the person approves the setup, the browser shows the Perspective's limits and their recorded state. The Perspective is enforced again when the run starts, and evaluated when the run has executed. A violated non-negotiable limit refuses the run, and nothing is published.

Before a reading

The platform checks the Perspective before it reads anything:

• its stored identity must authenticate, and any content digest supplied must match;
• a tombstoned Perspective is refused, as are draft and deliberation_required Perspectives;
• its executable form must be a version the runtime supports;
• its capability gates must allow the operation;
• each non-negotiable limit's measure is checked against the measures the target can provide, and any it cannot provide is recorded in a deliberation notice.

A retired Perspective can be replayed against past results. The assistant cannot select a retired Perspective for a fresh use.

Checking each limit

An evaluated limit also records its slack, the signed distance between the value and the threshold, except under !=.

Why a limit is skipped

A skipped limit is never satisfied or violated.

Strict obligations that cannot be checked

A non-negotiable MUST or MUST_NOT limit may be skipped. The reading then keeps the skip reason and records compliance as not established. It treats the option as non-compliant for the decision and adds a deliberation notice naming the limit. It never records the limit as violated without evidence.

A reading is infeasible when the evidence shows a non-negotiable limit violated. Otherwise it is deliberation_required when a strict obligation could not be checked or another deliberation notice is open. Otherwise it is ok. A governing Perspective refuses its operation in the first two cases, with PERSPECTIVE_CONSTRAINT_VIOLATED or PERSPECTIVE_DELIBERATION_REQUIRED.

What a reading attends to

Every measure a Perspective names receives one of six dispositions. A reader can tell a concern the result answered from one it had no measure for, and a Perspective that never examined a concern from one that examined it and ruled it irrelevant.

When the result declares its measures, those that no limit or goal uses are listed separately, as available and not examined.

Proxies and salience

An evaluated limit that comes from a mapping carries a one-line summary of that mapping's loss. The full loss profile and validity envelope are attached when they matter most. That is when the limit is violated or binding, or when the mapping's confidence is below 0.5. The record flags each limit that rests on a contestable mapping, with any assumptions the mapping lists.

Who shaped the Perspective

Each reading records who shaped the Perspective. It groups the claims by the standing they record. For each group it gives the claims contributed, how many became computations, and how many are sovereign. It lists the claims that were not computed, in their own words.

The reading also records the groups the result affects that had no part in shaping the Perspective, and the basis for saying so: why the group counts as affected and absent, who asserted it, how that was determined, and the evidence cited. The record does not fill the gap. It keeps a reading from presenting itself as complete when people it affects had no say in what it measures.

Standing is what the Perspective's author records. A Perspective speaks for a community only where that community wrote or authorized the version.

What the assistant receives

A reading through CHECK perspective_reading returns each criterion with its measure, comparison, threshold, deontic operator and tier. It also returns the outcome, the measured value and unit, the slack, any reason for not evaluating, and whether compliance is established. The reading names the Perspective version and its author, and carries fixed statements of its limits.

The reading states that it changed no run, no measurement and no evidence, and attached nothing to the source result. It is saved as a derived result. Its own label is fixed: grade OBS, claim strength CS1.

Publishing a reading

A reading can be published for public discussion. A published reading counts the limits evaluated, satisfied, violated and skipped, and states its blind spots in words. It can also say where it diverges from other readings, who it is meant for, what it redacts, and which discussions it belongs to. Its publication state takes one of three values.

A reading is published under its content hash, which binds the Perspective, the result it reads and the evaluation. Publishing a reading means signing it, and the one signature covers all three. The platform verifies the signature against the author's registered keys before it stores the reading, and refuses a reading that is unsigned or whose signature does not verify, so no one can publish a reading under someone else's name. A withdrawn reading is not published again; a fresh reading takes its place. The publication state and the signature sit outside the content hash.

Worked example: one closure, three readings

A bridge closes for repairs and traffic diverts onto the side streets. The result here is illustrative: four measured values, not a simulation run. The busiest street runs at 0.95 of its capacity. Each delivery round loses 14 minutes. 610 vehicles an hour pass the crossing. The route to the clinic takes 1,100 seconds.

Three people state Perspectives. All three share one claim, "the bridge closure diverts trips onto the side streets", measured as how full the busiest street is, <= 1.0, SHOULD, Preferred. It is satisfied in every reading. The platform compiles and evaluates their other concerns as follows.

Deliveries on time reads ok: its broken limits are only preferred. Trade at the door reads ok. Step-free crossings reads infeasible, because a non-negotiable limit is violated. Its curb limit could not be checked, so it also carries a deliberation notice and treats the closure as non-compliant. All three readings record the residents of the side streets as affected and absent: none of the three Perspectives speaks for them.

The crossing mapping shows what a translation declares:

Step-free crossings and Trade at the door read the same measure, vehicles per hour past a point. One sets 600 and loses the speed of the vehicles and the behavior of their drivers. The other sets 900 and loses whether the vehicles are stopped or moving.

Ranking options under a Perspective

A Perspective can rank the options in a decision, but only with the person's separate approval. The assistant asks to apply a published Perspective to a verified set of candidates. It binds every limit and goal to a measured value. The person reviews the exact priorities in the browser and signs the approval there.

The rule is fixed. Every non-negotiable limit must pass. Among the options that pass, the smallest total penalty on preferred limits comes first. Then comes the smallest total penalty on aspirational limits, then the highest weighted goal score. Options that tie on all three are selected together.

A ranking also requires the following:

• each value space's unit must match the unit of the measured value;
• every limit and goal needs a ratio or interval value space;
• no limit or goal may serve a sovereign claim;
• goals in different value spaces combine only through connected contracts with positive rates.

The approval binds the Perspective version, the candidates, the criteria and the person's key. The person can revoke it. At every use the platform checks that the Perspective remains published and that its source, the key and the approval are all current. The approval applies priorities to options. It does not make the evidence stronger.

Comparing Perspectives

Anyone can compare the Perspectives they are able to read: two at a time, layer by layer, or many at once. A comparison changes none of the Perspectives it compares.

Two Perspectives are compared layer by layer. Claims fall into those in one Perspective only, those in the other only, and those both hold, with or without differences. Mappings are sorted the same way. In the executable form the comparison covers gates, value spaces and their scales, contracts, limits and goals. It records which layers diverge.

When both Perspectives are compiled, the comparison also reports three kinds of disagreement about values:

• one measure that both Perspectives read with a different loss, threshold or confidence;
• a concern that only one Perspective measures;
• a coverage gap that both Perspectives share.

Group outcomes and change through time

A reading binds its criterion to the retained quantity, unit, aggregation, population and time window. Scalar, time-series and group outcomes can support different concerns without changing the underlying experiment. A total improvement and harm to a group can both remain visible. Comparing interventions preserves the same declared uncertainty design and identifies which outcomes and members entered each summary.

Many Perspectives at once

A place rarely has only two points of view. An analysis across more than two Perspectives sorts claims into those every Perspective holds, those only one holds, and those some hold. It separates four kinds of difference:

• factual disagreement: the same claim with a different predicate or object;
• interpretive divergence: the same subject measured in different ways;
• a concern that one Perspective represents and no other Perspective does;
• difference at each layer: claims, mappings, and limits and goals.

It also lists the coverage gaps that every Perspective shares. The analysis is itself a record, identified by its content, that can be kept and cited in discussion.

Agreement and independence

Where two or more Perspectives set a threshold on the same measure with the same comparison, the analysis looks for agreement. Two thresholds agree when they lie within 10% of the larger of the two. The analysis finds the largest group of Perspectives whose thresholds all agree with one another.

Agreement counts for more when it comes from independent sources. For each pair of agreeing Perspectives, the analysis measures how far the sources their claims cite overlap: the sources both cite, as a share of all the sources either cites. If no pair's overlap exceeds 30%, the Perspectives count as fully independent. Above 30%, independence falls in a straight line, reaching zero for Perspectives that cite exactly the same sources. The weight of the agreement is the share of the Perspectives that agree, multiplied by that independence. A limit in a reading can carry the weight and the Perspectives that agree on it.

Agreement between Perspectives shows where values converge. It is not evidence about a result, and it changes no grade.

Identity and authorship

A Perspective is identified by its content, not by its name. The content hash combines three parts:

• a digest of the authored material, including its claims and mappings;
• a digest of the executable representation;
• a record of the compiler and vocabulary that produced it.

Signatures, lifecycle state and governance fields sit outside the hash. A Perspective can be signed without changing which Perspective it is.

The person's browser holds a signing key that cannot be exported. The platform receives only the public key and signatures. Every published Perspective carries its author's signature, the fingerprint of the signing key and the time of signing. The signature covers the authored material. A Perspective can be published only when its author's signature verifies against an active key. The authored material must also recompile to exactly the stored executable representation.

Public keys are registered to the person with the period each one is valid, and the person's record shows that history, so earlier signatures stay verifiable after a key is replaced. Anyone can check a signature with only the Perspective and the public key, without asking the platform. A Perspective published for an organization is signed by a person on its behalf, with that person's membership recorded. A signature proves who authored a Perspective. It establishes nothing about whether the Perspective represents anyone beyond its author.

Lifecycle

The allowed transitions are:

• draft to compiled, or to deliberation_required;
• compiled back to draft, or on to published;
• deliberation_required back to draft, through edits to the authored material;
• published to retired;
• retired to tombstoned.

Resolving a deliberation appends a record of who resolved it and why. Revising a Perspective through a proposal clears its signature and its executable representation.

Visibility and copying

Visibility is checked whenever a Perspective is read or listed. Anyone who can read a Perspective can read all of its claims.

Only a published Perspective can be forked. A fork records the Perspective it came from and the reason for the fork. A Perspective composed from several others records each of them.

The assistant and the browser

The assistant can list the Perspectives it may see, read one, and read the state of its proposals. It can select any compiled or published Perspective the person can see, the person's own or someone else's, to govern an operation or to read a saved result, without asking the person. It cannot create, change, compile, sign, publish, fork, retire or tombstone a Perspective, or use one to rank a decision, on its own. The platform refuses an assistant's key for each of those acts.

Instead, the assistant submits a proposal for one of ten actions:

Each proposal gives its rationale and the visibility and fork policy it asks for. It grants no authorship, publication or permission. The person reviews it at its own browser address and adopts or rejects it. A proposal is pending, adopted, rejected or superseded. Only the author may revise, compile, publish, retire or tombstone a Perspective.

In the browser, the person sees the claims, mappings, value scales, contracts and conditions for use, and who may see and copy the Perspective. The page states that evidence keeps its original limits, and that signing values does not authorize their use in a decision. The review goes concern by concern: each row shows the measure, a proxy with what it loses, or no measure, and the person accepts, changes or rejects the row. The page then shows what a reading could and could not evaluate, with the reason. There the person can adopt or reject the proposal, compile a draft (the page calls this preparing it), sign it and publish it. The person can also place a reading beside another, save it or share it.