FPF Reference

    Worked dashboard and approval examples

    Preface node heading:worked-dashboard-and-approval-examples:21880

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    Worked dashboard and approval slice:

    A release dashboard shows a green approval-looking tile for Release-2026.05.08-prod. If the tile is a current view of the relevant GateDecisionRef plus evidence path and currentness path, it may carry bounded gate-passage reliance for that release scope and window. A claim that deployment happened still requires an A.15.1 work-occurrence source. If the gate source is missing or stale, treat the tile as orientation and source-finding until the team can name the release-work claim under repair, release-work position under repair, governing pattern for the claim or effect, and governing source for the gate decision, evidence path, and currentness path.

    StepRequired move
    Required project claim or effect kindRelease reliance, gate passage, compliance proof, assurance increase, evidence relation, or currentness relation.
    Gate decision sourceCite the current A.21 GateDecision or DecisionLogRef, gate profile, gate version, release scope or work target, scope, window, and replay or freshness pins. Without that source, the tile is not release permission or gate passage.
    U.Flow.ConstraintValidity sourceCite A.20 ConstraintValidity status or witness only when the claim is about U.Flow.ConstraintValidity, not about the gate decision itself.
    Evidence and currentness sourceUse A.10 for the dashboard query, publication-carrier integrity, evidence refs, time, window, freshness field, revocation source or revocation record, verifier context, relying context, and rival explanation such as stale display or copied status.
    Assurance sourceUse B.3 only if the tile is being used to raise readiness, compliance, trust, safety, release confidence, R, F, G, or CL; otherwise no assurance tuple is being claimed.
    Repaired gate-use relianceWith the decision and evidence path recovered, rely on gate passage only for the named release scope or work target, environment, gate profile, gate version, time, and window; a claim that deployment happened still needs an A.15.1 work-occurrence source.
    Blocked overreadsThe dashboard color does not create approval, permission, compliance proof, rollback success, work occurrence, or assurance by display.

    Approval memo green-tile case:

    An approval memo may carry an approval claim when it exposes the A.2.9 SpeechActRef, actor and role assignment if claimed, affected release scope or work target, judgement context, time, window, publication-carrier refs, evidence refs, and instituted effect being claimed. That carries the bounded approval claim or effect only. It does not prove that release, deployment, rollback, or other work occurred; that performed-work claim still needs the dated A.15.1 work-occurrence source plus any A.10 evidence path required for the relying context.

    Credential and status green-tile case:

    A credential or status response may carry holder reliance, status reliance, or currentness reliance only inside the issuer or governing status register, holder binding or subject binding, verifier context, relying context, proof result or status result, revocation source or revocation record, freshness field, and effective window that it exposes. It does not by itself carry release, work occurrence, gate passage, engineering justification, evidence for underlying operational facts, or contextual permission; those uses require the governing source for the claim or effect.

    Situation viewpoint prompts:

    Viewpoint or source-restoration concernPrompt
    Acting practitionerWhat can I safely do next without turning the encountered episteme or episteme publication into unsupported work or reliance justification?
    Release engineerWhich A.21 gate decision, decision log, release scope, work target, and A.15.1 work occurrence are separate here?
    Issuer, gate, evidence, or role-assignment sourceWhich source, status, decision ref, or evidence path needs exposure or repair?
    Audit or peer-review viewpointWhich evidence path, decision ref, speech-act ref, commitment, work occurrence, or assurance claim needs recoverability?
    Boundary claimantWhich words need typed claim IDs before they can guide work or reliance?
    ManagerIs repeated ambiguity source-relation repair work rather than another manual check for the acting practitioner?
    LLM user or tool userWhich governing source does the explanation help find, and which operative claims still need an A.10 claim-bound source relation?
    Security or compliance sourceWhich revocation, currentness, proof, status, source order, or supersession source needs exposure?
    Model or data sourceWhich intended use, evaluation condition, version, window, limitation, and evidence path bound the model or data documentation?
    Assurance viewpointWhich named claim actually has a B.3 assurance claim, with what assurance tuple, evidence path, limitations, and reopen condition?

    Search cues for A.15.4 include: approval, approval-looking display, authorization, authorization-looking display, permission, permission display, allowed wording, green dashboard, release tile, release readiness, model card, datasheet, data card, provenance, provenance mark, attestation, attestation label, credential, credential badge, generated explanation, copied review, copied approval, review summary, compliance-looking mark, delegation, delegation display, revocation, revocation status, gate passed, gate passage, rollback successful, rollback cue, and assurance label. These are retrieval cues only; decide the governing source and governing pattern or source relation from the work or reliance question under repair, not from the displayed word, publication-carrier name, or source name.

    Work and reliance disposition table for authority-looking cases:

    Question under repairStart inFirst useful output
    Can this encountered episteme publication, publication face, publication carrier, rendering, or cue guide work or reliance?A.15.4Candidate next U.WorkPlanning, U.Work, or reliance move; governing pattern for the claim or effect; governing source; minimum relation-governed next move.
    Is the problem boundary, policy, API, schema, or connector wording?A.6 or A.6.BTyped L-*, A-*, D-*, and E-* claims before the work claim or reliance claim is used.
    Is the problem evidence, currentness, provenance, credential status, generated-source relation, copied-source relation, or source-chain recovery?A.10Claim-bound evidence path, currentness path, and relation-governed or blocked use.
    Is the problem assurance, readiness, safety, compliance, trust, release confidence, or change in R, F, G, or CL?B.3Typed assurance claim, no-assurance-use disposition, or downgraded or rejected assurance use.

    Display guidance for bounded status: a visible status meant to guide work should expose source type, reference or link named by value, freshness, window, scope, unsupported work claim, unsupported reliance claim, and unsupported effect. For example, prefer Gate check passed; GateDecisionRef; release scope; environment; window; not compliance proof, rollback success, or assurance increase over a bare approval-looking label.

    Incident-learning fields for authority-looking overread: encountered episteme or episteme publication, work or reliance claim under repair, work-relevant P2W claim under repair, or P2W chain position under repair, governing pattern and governing source for the claim or effect, actor and role assignment, affected work target or claim, context, window, missing or stale source U.Episteme, source U.EpistemePublication, register entry, or governing source; governing FPF relation or role assignment accountable for exposing or repairing that missing source, plausible overread, safe disposition used now, and upstream repair work for the source, dashboard, explanation, credential view, boundary wording, publication face, or publication carrier.

    Contestability and redress relation: when an authority-looking case affects person or team status, access, assignment, responsibility, release blockage, compliance claim, or safety-impacting work, name the review relation or redress relation before the work claim or reliance claim hardens. The relation should name the disputed source or claim, the role assignment accountable for refreshing or correcting that source, the evidence relation or status-currentness relation to reopen, the safe interim disposition, and the time and window for review.

    Lintable overread cues:

    Lint signalGoverning relation named by value
    approved, authorized, allowed, recommended, or guaranteed in boundary, API, schema, or policy wordingSplit through A.6 or A.6.B into L-*, A-*, D-*, and E-*; use A.6.C, A.2.8, and A.2.9 for agreement-like wording when agreement, commitment, or speech-act claims are being made.
    Dashboard tile, status color, or release tile used as release evidence or gate passageRequire A.21 GateDecision or DecisionLogRef plus A.10 evidence path and currentness path.
    Credential screenshot or badge used as permission, authorization, role-assignment relation, or status relationRequire A.10 issuer, holder, verifier, status, currentness, and relying-context fields, then the A.2.8, A.2.9, A.2.1, A.6.B, or A.21 source named by value for the required permission, authorization, role assignment, status, gate claim, or gate effect.
    Generated explanation uses authorized, approved, or similar wordingUse E.17.EFP for explanation relation and source-finding relation and A.10 claim-bound source relation; issue, approval, gate, and commitment claims still need A.2.9, A.21, or A.2.8.
    Model card, datasheet, label, or note cited as readiness, safety, compliance, or release confidenceRequire a typed B.3 assurance claim, intended-use match, evaluation condition, limitations, and A.10 evidence path.
    Provenance or attestation label cited as truth, safety, release, or permissionRequire A.10 bounded provenance claim or process claim plus separate evidence for truth, safety, release, permission, or assurance.
    Evidence, assurance, gate, or work-occurrence words without the governing source that carries that claim or effectRecover the A.10 evidence relation, B.3 assurance claim, A.21 gate decision, or A.15.1 work-occurrence record respectively before the work claim or reliance claim is used.

    Stress cases for practice:

    CaseExpected A.15.4 disposition
    Green release dashboard tile with no GateDecisionRef.Source-finding only; recover A.21 decision or decision log plus A.10 evidence before gate-passage reliance.
    Copied approval from last month.Recover original A.2.9 SpeechActRef, currentness, freshness, and any A.2.8 commitment or A.21 gate source needed for the claim.
    Credential badge screenshot after revocation.Treat as contested credential-currentness; use A.10 issuer, holder, verifier, source-status, and revocation relation and do not infer permission.
    Generated explanation says authorized by policy.Use E.17.EFP for explanation and source-finding and A.10 claim-bound source relation; issuing, gate, and commitment claims still need their own sources.
    Boundary wording says guaranteed approved for production.Split through A.6 or A.6.B; if agreement-like or promise-bearing, unpack through A.6.C, A.2.8, and A.2.9.
    Dashboard says green while decision log says blocked.Treat as conflicting sources; name source order, governing decision source, freshness policy, and supersession rule before the work claim or reliance claim is used.
    CRISPR lab dashboard says the guide edit is ready.Treat the dashboard as orientation or source-finding until the protocol, approval record or gate record, role-assignment source, evidence path, current lab source, and U.WorkPlan for the intended edit are recoverable. A ranked guide row or readiness tile does not create biological-intervention permission, safety, or performed work.

    Last Updated: 2026-06-17 — upstream FPF commit 646b0b9b (github.com/ailev/FPF)