PRD: ogsfrompoly.com landing page v1 — open-book prediction-market intelligence

[tkowalczyk]

Problem Statement

The poly-track project — a Polymarket skilled-trader detector grounded in two 2026 academic papers (Gomez-Cram et al.; Akey et al.) — has substantial credibility assets: replicated methodology, a populated warehouse, weekly/monthly playbook outputs, and a live alert pipeline. None of it is publicly visible. Institutional readers (prediction-market platforms, quant funds, data buyers, VCs) cannot evaluate the work without a direct introduction, and there is no public surface that compounds reputation over time as new results land.

The stated goal is to be acquired by Polymarket — or, failing that, to be visibly the prediction-market intelligence layer that any acquirer (Kalshi, Dune, Chainalysis, market-data buyers) discovers when they look. Today there is nothing to discover.

Solution

A landing page at ogsfrompoly.com that publishes the project's methodology, weekly and monthly "financial statements" (strategy track record + project P&L), and a series of technical articles derived from the build history of poly-track itself. The page embraces the in-group brand name as a credibility signal, leans on a distinctive opinionated aesthetic (Hermes-by-Nous as reference), and is designed to be consumed by LLM agents as well as humans — every page is also served as raw markdown at /<slug>.md, and an llms.txt index makes the entire site agent-readable.

There is no email capture, no newsletter, no signup. Distribution is RSS and the .md feed. The acquirer's own intelligence tooling (or BD team) finds it.

Wallets are never published by full address. Statements show aggregate counts, distributions, hit rates, and pseudonymous truncated IDs (wallet_a3f…) — never live alpha.

User Stories

Institutional reader (acquirer / VC / data buyer)

1. As an institutional reader, I want to land on the homepage and understand within five seconds what this project is and why it is credible, so that I decide to keep reading.
2. As an institutional reader, I want a clear hero claim — "We measure who is actually skilled on Polymarket — and we show our work, weekly" — so that I know the cadence promise upfront.
3. As an institutional reader, I want a methodology page that cites the academic papers and explains the sign-randomization skill test, so that I can evaluate rigor without reading the source code.
4. As an institutional reader, I want to read the latest weekly and monthly statement without account creation, so that there is no friction between curiosity and evaluation.
5. As an institutional reader, I want to see hit rates, alert counts, hypothetical PnL on a stated bankroll, and category coverage in each statement, so that I can audit the track record.
6. As an institutional reader, I want to see project operating costs and (if any) revenue published openly, so that I understand the runway and the seriousness of the open-book stance.
7. As an institutional reader, I want a discreet way to make an acquisition / partnership inquiry (footer-level contact), so that I can act when ready — without the page screaming for attention.
8. As an institutional reader, I want the site to load quickly and look like it was made by serious people, so that the aesthetic itself signals credibility.
9. As an institutional reader, I want past statements to remain accessible at stable URLs, so that I can audit historical claims against current ones.

Author / maintainer

10. As the author, I want to add a new statement by committing a markdown file with valid frontmatter, so that publishing is one PR rather than a CMS workflow.
11. As the author, I want CI to reject malformed frontmatter before merge, so that the schema is enforced and feeds never break in production.
12. As the author, I want RSS, llms.txt, and the sitemap to regenerate automatically from the content collection, so that I never maintain a manual index.
13. As the author, I want each new content entry to be automatically available at both /<slug> and /<slug>.md without any per-route boilerplate, so that LLM-discoverability is the default.
14. As the author, I want a typography and component vocabulary already in place (display headings, terminal install snippet, statement table), so that adding a page is composition, not design.
15. As the author, I want the v1 site to ship with one handcrafted sample statement that demonstrates the format, so that subsequent statements have a template to follow.
16. As the author, I want the content schema to be the stable interface between this repo and the future poly-track automation, so that v2 cross-repo CI wires in without changing the LP.

LLM agent (and the human who runs it)

17. As an LLM agent, I want every article and statement available at a predictable /<slug>.md URL returning text/markdown, so that I can ingest the content without HTML parsing.
18. As an LLM agent, I want an llms.txt index at the site root listing every available .md URL with a one-line description, so that I can crawl the site efficiently.
19. As an LLM agent, I want an RSS feed with full content (not summaries), so that subscribers receive new statements in machine-readable form.
20. As a human who pasted the homepage install snippet into Claude or ChatGPT, I want the LLM to be able to answer "what does ogsfrompoly do?" substantively from the feed alone, so that the install snippet is not theatre.

Operator (post-launch)

21. As the operator, I want privacy-friendly analytics (Cloudflare Web Analytics) so that I can see traffic volume and referrers without setting cookies or displaying a banner.
22. As the operator, I want to identify when corporate IP ranges from Polymarket / Kalshi / etc. visit the site, so that I have a weak but real signal of acquirer interest.
23. As the operator, I want all secrets (Cloudflare API tokens, future PATs) to live in Cloudflare and CI secrets stores, never in the repo, so that an open-source LP repo is safe.

Implementation Decisions

Positioning & content

• Audience: institutional, VC, broad acquirer set — not Polymarket-exclusive.
• Brand: ogsfrompoly retained as-is. Owned cheekiness is treated as a credibility signal, not a liability.
• Voice / aesthetic reference: hermes-agent.nousresearch.com — bold display type, terminal/install-snippet moments, opinionated copy embedded throughout, function-forward.
• Disclosure policy: methodology + aggregate results only. No live alpha. Wallets appear only as truncated/hashed IDs (e.g. wallet_a3f…).
• No email capture. Distribution is RSS + .md feed. A discreet contact link in the footer is the only conversion surface.

Content types (v1)

• Statement (weekly) — short cadence artifact, strategy track record snapshot, opinionated commentary.
• Statement (monthly) — long-form artifact: strategy track record table + project P&L (revenue, opex, runway) + monthly commentary.
• Methodology page — single canonical page citing the source papers, explaining categories tracked, what is and isn't published, wallet anonymization rationale.
• Homepage — hero + install snippet + latest-statement teaser + methodology link + footer.

Content types (v2, deferred)

• Build Log article series — narrative articles about how poly-track was built, derived from git history and code changes. Generation method (LLM-summarized commit ranges vs hand-written) to be decided in v2 discovery.
• About / team page.

Major components

1. Content Surface — Astro pages for the four v1 routes (home, methodology, statements index, single statement). Layout + component primitives.
2. Content Schema (deep module) — Zod-validated frontmatter contracts for statement and article collections. The stable interface between LP and any upstream content producer (manual today, automated in v2). Enforced by Astro content collections at build time and by CI on PR.
3. Dual-Format Serving (deep module) — Every content entry resolves at both /<slug> (HTML) and /<slug>.md (raw markdown, Content-Type: text/markdown). Single helper takes a content entry and emits the markdown response; a catch-all route wires it. Adding a new content type requires no per-route boilerplate.
4. Feed Generators (deep module) — rss.xml, llms.txt, sitemap.xml generated from the same content collections. Single module: (collections) → feed string. Format renderers hidden inside. Feeds regenerate deterministically on content change.
5. Brand / Design Primitives — Tailwind v4 token set (typography scale, monospace, color), a small set of shared components (display heading, terminal install-snippet block, statement table, statement card).
6. Analytics — Cloudflare Web Analytics script tag. No cookies, no banner.
7. Cross-repo Ingest (deferred to v2) — A GitHub Action in poly-track that runs the report CLI on a cron, opens a PR (or pushes a branch) on this repo via a fine-scoped GitHub App token, triggering a Cloudflare deploy on merge. v1 ships with manual commits; the Content Schema (component 2) is the stable interface so v2 wires in without changes to the LP.

Technology decisions (stakeholder-stated)

• Astro 6 on Cloudflare Workers (this template), output: 'server'.
• Tailwind CSS v4 (no JS config; theme via @theme in CSS).
• TypeScript strict.
• Custom domain ogsfrompoly.com via Cloudflare (custom_domain: true on the route).
• Cloudflare Web Analytics (free tier).
• Content lives as markdown in src/content/ — Astro content collections. Not a CMS. Not a git submodule from poly-track.

Out-of-band setup (not code)

• Register ogsfrompoly.com (availability not yet verified — confirm before lock-in).
• Provision Cloudflare zone, point DNS via custom_domain: true.
• Enable Cloudflare Web Analytics for the zone.

Validation Strategy

Automated acceptance criteria (the three deep modules)

Component	Acceptance criterion
Content Schema	A PR adding a markdown file with malformed frontmatter (missing required field, wrong type) fails CI before merge. Error message points at the bad field. Test: fixture file with each invalid case asserts schema rejection.
Dual-Format Serving	For every entry in every content collection, two integration assertions hold: (a) /<slug> returns text/html and renders the content; (b) /<slug>.md returns text/markdown with a body whose payload matches the source markdown. Test iterates over all fixture content; no content type may be exempt.
Feed Generators	Snapshot tests against a fixture content collection. Adding, removing, or modifying a fixture entry produces a deterministic, reviewable diff in rss.xml, llms.txt, and sitemap.xml. CI fails on accidental non-deterministic output (e.g. timestamps without seeding).

Manual acceptance criteria

Component	Acceptance criterion
LLM Install Snippet	The install snippet shown on the homepage (e.g. a curl ogsfrompoly.com/llms.txt line) is pasted into Claude and ChatGPT. The LLM is asked "what does ogsfrompoly do?". Both produce a substantively correct answer derived from feed content alone (no homepage scraping). Documented as a one-paragraph launch check.
Analytics	After deploy: visit the site, confirm the Cloudflare Web Analytics dashboard registers the visit within the documented latency. Open browser devtools, confirm no cookies are set by any first-party or third-party script.

Per-user-story verification

• Stories 1–9 (institutional reader): manual walkthrough on staging before launch.
• Stories 10–16 (author): automated by the schema + dual-format + feed tests above.
• Stories 17–20 (LLM agent): covered by the dual-format + feed automated tests, plus the LLM install snippet manual check.
• Stories 21–23 (operator): analytics manual check + standard repo hygiene review (no secrets committed, deployment uses Cloudflare secrets).

Definition of "v1 launched"

All of the following are true:

1. ogsfrompoly.com resolves to the deployed Worker over HTTPS.
2. Homepage, methodology page, statements index, and at least one real statement are live.
3. /<slug>.md works for every published entry.
4. rss.xml, llms.txt, sitemap.xml are reachable and valid.
5. All three automated acceptance tests pass in CI.
6. Both manual acceptance checks (LLM install snippet, analytics) pass and are recorded.

Out of Scope

The following are explicitly out of scope for v1 and will be addressed in later iterations:

• Cross-repo automation from poly-track. v1 publishes via manual commits to this repo. The schema is designed to be the stable interface so the v2 GitHub Action wires in without LP changes.
• Build Log article series. Concept agreed; generation method (LLM-summarized commits vs hand-written) deferred to v2 discovery.
• About / team page. Deferred to v2.
• Backfilled historical statements. v1 ships with one handcrafted sample. Historical reconstruction is v2+ work.
• Email newsletter / signup. Explicitly rejected; distribution is RSS + .md feed only.
• Comments, community, social-media login. Out of scope indefinitely. Publishing-only stance.
• Paid product / pricing pages. Out of scope; the project is not productized for retail and is not seeking subscription revenue.
• Internationalization. English only.
• A formal disclosure / anonymization policy document. Acknowledged as needed; should live in the upstream poly-track repo as the authoritative reference, then be cited from the LP methodology page. Drafting it is a separate task.
• Authoring tooling beyond markdown + git. No preview UI, no CMS, no editorial workflow.

Further Notes

Design references

• Voice / aesthetic anchor: hermes-agent.nousresearch.com — bold display type, install-snippet moments, opinionated function-forward copy.
• The brand-name choice is deliberate. The first-paragraph copy on every long-form page should ground a cold reader: "ogsfrompoly is a Polymarket skilled-trader research project. We publish methodology, aggregate results, and open-book financials." This sentence does the work that a more corporate name would do passively.

LLM-discoverability convention

• llms.txt at the site root lists every .md URL with a one-line description. Regenerated from the content collection at build time — never hand-maintained.
• The homepage install snippet should be copy-pastable and produce a real result. The exact form (curl … | <agent> style) to be finalized during build.

Open questions to resolve during build

1. Exact frontmatter fields for statement (weekly vs monthly) and for future article — drafting a one-page schema spec is the first task of v1 implementation.
2. Hero copy: three variants to be drafted in the Hermes voice; one chosen.
3. ogsfrompoly.com registrar choice and availability confirmation.
4. PAT vs fine-scoped GitHub App for the v2 cross-repo automation — recommend GitHub App. Not a v1 decision.

Project-specific constraints already accepted (from CLAUDE.md)

• Max 500 lines per source file.
• pnpm types, pnpm test, pnpm lint, pnpm knip must pass before declaring v1 done.
• Tests live next to source as *.test.ts; pure functions only in unit tests; integration tests for side-effecting orchestrators.
• All Cloudflare bindings accessed via import { env } from "cloudflare:workers".
• wrangler.jsonc with three env blocks; custom_domain: true preferred over routes-with-zone.