Publication eligibility

What the check is

Publication eligibility on GARPedia is a render-time check, not a workflow. Once the renderer has a GarpediaRenderedRecord in hand, the renderEligibility helper inspects the record's status, its position in the corpus lifecycle, the resolution state of its anchors, the verification state of its citation spans, and the presence of any open whole-record dispute, and returns a boolean publication_eligible flag together with the reasons backing the decision and a deterministic timestamp.

The check does not approve a record for publication, route a record into a review queue, or change any underlying state. The underlying record was admitted, reviewed, and promoted upstream by the GARP SDK and the operator surface. The eligibility check is the render-time question of whether the public renderer should treat this record as publication-eligible right now.

Fields that participate

The check reads five dimensions from the rendered record. Each one can change the outcome on its own, and the reasons array surfaces the specific dimensions that are blocking eligibility for any given record.

• statusA Counterpose-style record state. Statuses such as candidate, under_review, withdrawn, and superseded keep a record from being publication-eligible at render time even when other fields are clean.
• corpus_lifecycleWhere the record sits in the publication lifecycle, separate from status. A record can be active in status while sitting in draft or candidate in lifecycle, and the renderer should not treat it as publication-eligible until lifecycle reaches a published or amended_in_place state.
• anchor_resolution_statusWhether the record's citation-span and cross-reference anchors all resolve. A record with unresolved anchors is not publication-eligible, since the rail cannot present supports that the renderer cannot follow.
• citation_spans[].verification_stateThe verification state recorded by the verbatim fragment lint. The presence of any unverified span among the cited spans of the record blocks eligibility, since the reader cannot rely on a span that did not clear the lint.
• disputes[].scopeOpen disputes against the whole record block eligibility. Disputes scoped to a section, claim, source support, citation span, or cross reference do not block eligibility on their own; they are surfaced by the DisputePanel without changing the render-time eligibility outcome.

Why the check is deterministic

The check produces the same boolean and the same reasons for the same record, every time it runs, because every input field is a stable property on the rendered record. The computed_at timestamp uses the record's rendered_at value and falls back to a fixed bootstrap-mode timestamp when the rendered_at field is absent, so cached pages and rebuilt pages produce the same eligibility output.

Determinism matters at render time because a public surface cannot afford an eligibility flag that changes between two views of the same record. If the underlying record changes upstream, the rendered record changes with it; the eligibility check then reflects the new state, not a side effect of when the page was viewed.

Where eligibility is rendered

Each record page renders the eligibility outcome in the RecordHeader, with the reasons available behind the badge. The method panel at the foot of each record page then puts the profile's admission boundary, the discovery posture, and the control-discharge notes alongside the eligibility outcome, so a reader can see, in one place, both the rule the record cleared upstream and the render-time decision the public surface reached.

• Back to /method
• Continue to projection records