{"data":{"id":"a4e84cd0-ef3d-4728-b7ca-b4dc6af7941e","slug":"how-coinbot-publishes","title":"How CryptoSocial publishes: one article, three representations","excerpt":"Every post here is served three ways from a single source of truth — a rendered page for people, structured data for search and answer engines, and JSON for bots. Here is how that works and why it is built this way.","body_markdown":"\r\nMost research sites are written for people and then, much later, bolted onto an API. That ordering shows: the API lags the site, the two disagree, and machine consumers get a second-class version of the truth.\r\n\r\nCryptoSocial inverts it. A post is stored once and served three ways.\r\n\r\n## The three representations\r\n\r\nEvery published article exists simultaneously as:\r\n\r\n| Form | Where | Consumer |\r\n|---|---|---|\r\n| Server-rendered HTML | `/blog/{slug}` | readers |\r\n| JSON-LD structured data | in the page `` | search and answer engines |\r\n| JSON | `/api/v1/posts/{slug}` | trading bots, agents |\r\n\r\nAll three are generated from the same database row by the same data-access function. They cannot drift apart, because there is nothing to drift *from*.\r\n\r\n## Why server rendering is not optional\r\n\r\nAI crawlers read the HTML a server returns. They do not execute JavaScript.\r\n\r\nA page that fetches its content after hydration is, to those crawlers, an empty shell. So content routes here are Server Components, and interactivity is pushed to the smallest leaf that needs it.\r\n\r\n> If the content is not in the initial HTML payload, assume no machine will ever see it.\r\n\r\n## Reading the JSON twin\r\n\r\nThe API needs no key for reads:\r\n\r\n```bash\r\ncurl -s https://www.cryptosocial.media/api/v1/posts?limit=5 | jq '.data[].title'\r\n```\r\n\r\nA single post, by slug:\r\n\r\n```bash\r\ncurl -s https://www.cryptosocial.media/api/v1/posts/how-coinbot-publishes\r\n```\r\n\r\nResponses are versioned under `/api/v1/`. Within a version, changes are additive only — a new optional field is fine, a renamed or removed one is not. Bots do not read changelogs, so the contract has to hold.\r\n\r\n## What we will not do\r\n\r\nA few standing constraints, worth stating plainly because they are easier to promise than to keep:\r\n\r\n- **No unbacked numbers.** Performance figures appear only when they are computed from records that exist. Until then, the space stays empty rather than filled with a placeholder.\r\n- **Sources are cited as links**, not as vague appeals to \"on-chain data\".\r\n- **Losses are published alongside wins.** A track record showing only the good trades is a misrepresentation, however accurate each individual row may be.\r\n\r\n## Where this is going\r\n\r\nThe publishing pipeline described above is the foundation. Trading signals, accuracy tracking, and webhook delivery build on the same three-representation contract rather than replacing it.\r\n\r\n*Research and analysis only. Nothing here is financial advice.*\r\n","cover_image_url":null,"category":"ANNOUNCEMENT","tags":["methodology","api","transparency"],"status":"PUBLISHED","source":"HUMAN","author_id":null,"author":null,"reading_minutes":3,"published_at":"2026-09-08T10:30:20.886542+00:00","created_at":"2026-09-08T10:30:20.886542+00:00","updated_at":"2026-09-10T10:36:39.593859+00:00"}}