Counterpose bridge

What the bridge is

Counterpose is the first public publication platform built on governed analytical records. GARPedia is the read and render surface for profile-eligible governed records. The two systems are intentionally separate. Counterpose holds editorial authority for its signals; GARPedia mechanically renders the records Counterpose has already decided are public.

The Counterpose bridge is the planned mechanism by which Counterpose tells GARPedia that a particular signal is eligible for cross-render. The bridge is a small artifact containing the signal's identity, the editorial state, the export state of its supporting registries, and the public render policy that should apply on GARPedia. Counterpose decides what is eligible and ships the artifact; GARPedia consumes the artifact and renders the record under a profile overlay.

What the bridge is not

• It is not a live API. There is no GARPedia client that reaches into a running Counterpose instance, and there is no scrape of the Counterpose corpus.
• It is not editorial input from GARPedia. GARPedia does not select, recommend, or rank Counterpose signals; it does not editorialize on top of the Counterpose body.
• It is not a publication workflow. Approval, dispute adjudication, withdrawal, and any other governed-write action remains on the Counterpose side.
• It is not implemented as a real cross-render at this checkpoint. The schema, the synthetic fixtures, and the adapter stub exist; no real Counterpose signal has been cross-rendered through the bridge. Captured Counterpose editorial does reach the public atlas, but by a separate static republication path, not by this bridge — see the next section.

Captured editorial is a separate, static path

The bridge above is a synthetic demonstration of a future live cross-render lane and renders no real Counterpose content. Separately from the bridge, GARPedia statically republishes ten captured Counterpose editorial records — the CP-SIG-* records. They do not arrive through the bridge; they are a committed, read-only projection. This section exists so the four things a reader can encounter on this site are not confused with one another.

• captured editorialThe ten CP-SIG-* records are captured Counterpose editorial that GARPedia republishes as editorial / unverified republication only. Each is rendered under the counterpose_publication profile and carries the render-path label source_kind: captured_counterpose_signal, so a reader can tell captured editorial from a synthetic fixture at the point of display. GARPedia republishes the captured editorial only: it is not source-verified, not receipt-backed, and not admitted as fact by GARPedia, and no private source text is rendered. Every CP-SIG-* page carries an editorial-republication notice that states this in plain view.
• synthetic fixturesThe synthetic signal at SYN-CP-SIG-0001 and the synthetic bridge fixtures above are fictional and remain synthetic. They share the counterpose_publication profile shape but carry no captured provenance, so they are never relabelled as captured editorial and the editorial-republication notice does not render for them. A synthetic fixture demonstrates the record shape; it is not republished editorial.
• verified / source-supportedA record presented as source-supported has registered source captures and at least one verified citation span — a different posture from editorial republication. Captured CP-SIG-* editorial has neither, so it is never shown as verified or source-supported. The render-time check that decides this is described at /method/publication-eligibility.
• projection bundlesA projection bundle is read-only metadata about a projection — references and summary counts, never the body and never the source text. It is described at /method/projection-bundles and is distinct from both a rendered record and the captured editorial above.

The distinction is enforced in code, not just in copy: the editorial-republication notice is gated on captured provenance (source_kind = captured_counterpose_signal under the counterpose_publication profile), not on the profile alone, so a synthetic counterpose-profile fixture keeps its prior render path and is not collapsed into captured editorial.

Synthetic bridge fixtures

Three synthetic fixtures live in the repository as TypeScript modules: an eligible fixture for the synthetic Counterpose-shaped record at SYN-CP-SIG-0001; a blocked fixture for a synthetic document that is intentionally not eligible for cross-render; and a second blocked fixture where only the source-family export is deferred (OCR-alignment narrative). All three are fictional. No real Counterpose document id, title, slug, publisher, source name, or signal text appears in any of them.

The detailed sections below render each fixture's artifact contents alongside the structured outcomes of the validator (validateCounterposeBridgeArtifact), the synthetic-only adapter (bridgeToRenderedRecord), and the eligibility projection (mapCounterposeBridgeToRenderEligibility). The panel runs against the same code path that a future real adapter would inherit.

Eligible fixture

The eligible fixture reports a clean public-safe policy on all four families, an all_editions_exported edition state, and a recorded editorial approval reference. It maps to the existing synthetic record at /records/SYN-CP-SIG-0001. The synthetic adapter does not yet support any other counterpose_document_id; a real Counterpose signal cross-render is a future, editorially gated lane.

What the synthetic demonstration shows

• This is a synthetic bridge demonstration. The fixtures, the validator outcomes, and the adapter outcomes above are all computed from in-repository TypeScript modules.
• No live Counterpose content is rendered through the bridge. The only Counterpose-shaped record the bridge demonstration maps to is the synthetic signal at /records/SYN-CP-SIG-0001, also walked through at /examples/counterpose-signal. Captured Counterpose editorial reaches the public atlas by the separate static republication path described above, not through this bridge.
• Counterpose remains the publication authority. The eligible decision is recorded on the Counterpose side; GARPedia does not select, approve, or override it.
• GARPedia renders only bridge-eligible records. An invalid or blocked artifact resolves to a structured error rather than a rendered page. There is no alternate render path for blocked bridge artifacts.
• Blocked bridge artifacts remain inspectable but non-rendering. The blocked fixture is visible above so the method surface stays honest about what the bridge refuses, but it never produces a record page.

Where to read more

The publication-eligibility explainer at /method/publication-eligibility describes the render-time check that runs against every record, including a record that arrives through the bridge. The bridge does not replace that check; it adds a Counterpose provenance gate in front of it.