{
  "service": "ai-insights-for-humans",
  "version": "0.6.0",
  "title": "AI Insights for Humans",
  "description": "A working notebook of practical AI interpretability, prompting, reliability, and tooling notes for people who want evidence instead of hype.",
  "url": "https://tips.platphormnews.com",
  "publisher": "PlatPhormNews",
  "attribution": "Credit AI Insights for Humans by PlatPhormNews and link to the canonical entry URL.",
  "generatedAt": "2026-07-21T08:35:50.365Z",
  "stats": {
    "totalEntries": 67,
    "kindCounts": {
      "tip": 15,
      "method": 39,
      "tool": 13
    },
    "tags": [
      "agents",
      "dictionary",
      "evals",
      "field",
      "governance",
      "integration",
      "interpretability",
      "notes",
      "platform",
      "prompting",
      "reliability",
      "security",
      "tooling",
      "verification"
    ],
    "tagCount": 14,
    "readingPathCount": 8,
    "latestEntry": {
      "id": "mind-microscope",
      "kind": "method",
      "title": "Use a mind microscope, not mind reading",
      "body": "You cannot open an AI model and read a private thought. You can inspect signals: tokens, attention, features, circuits, traces, tests, and receipts. The skill is knowing what each signal can prove and where it can fool you.",
      "tag": "interpretability",
      "date": "2026 · 06 · 30",
      "note": "A signal is a clue. A causal intervention is stronger evidence.",
      "extended": [
        "The phrase seeing inside AI is useful only if we keep it honest. We are not watching a human-like inner monologue. We are reading instruments that expose partial evidence about how an answer formed.",
        "Token probabilities show fragile words. Attention can show routing clues. Probes can show where a concept is readable. Sparse features can separate tangled activation directions. Activation patching and circuit tracing can test whether a component actually changes behavior.",
        "The AHA for readers is that no single view is the mind. The strongest review layers several instruments and then asks what changed in the output when the internal signal changed."
      ]
    },
    "latestPublishedAt": "2026-06-30",
    "totalParagraphs": 188,
    "ahaMomentCount": 67
  },
  "tags": [
    "agents",
    "dictionary",
    "evals",
    "field",
    "governance",
    "integration",
    "interpretability",
    "notes",
    "platform",
    "prompting",
    "reliability",
    "security",
    "tooling",
    "verification"
  ],
  "readingPaths": [
    {
      "id": "research-trends-and-demos",
      "title": "Research trends and demos",
      "description": "A source-backed path for seeing AI internals, loops, OpenClaw toolchains, webhook receipts, and portable prompt contracts.",
      "entryIds": [
        "mind-microscope",
        "circuit-tracing-is-partial",
        "agent-loops",
        "openclaw-toolchain-dry-run",
        "webhook-delivery-lifecycle",
        "cross-model-prompt-contract",
        "context-is-the-prompt",
        "benchmark-time-horizon",
        "reasoning-as-search",
        "tool-protocols-over-adapters",
        "prompt-injection-is-a-tool-boundary",
        "source-ledger-habit"
      ]
    },
    {
      "id": "focus-fieldwork",
      "title": "Field framing",
      "description": "A facilitator path for turning notebook ideas into shared walkthroughs, demos, checkpoints, and self-quizzes.",
      "entryIds": [
        "plain-then-precise",
        "artifact-questions",
        "term-first-fieldwork",
        "explain-inspect-repair-loop",
        "concept-ladder",
        "aha-from-mistake",
        "glossary-before-demo",
        "aha-checkpoints",
        "readiness-red-yellow-green",
        "focus-fullscreen-mode",
        "self-quiz-cards"
      ]
    },
    {
      "id": "dictionary-notes-workflow",
      "title": "Dictionary and Notes workflow",
      "description": "How to move from reader notes to shared vocabulary without pretending AI-generated definitions are approved truth.",
      "entryIds": [
        "dictionary-backed-verification",
        "definition-vs-proof",
        "note-to-definition-pipeline",
        "notes-as-observation-log",
        "dictionary-provenance-check",
        "human-approval-queue",
        "glossary-drift-watch"
      ]
    },
    {
      "id": "integration-design",
      "title": "Integration design",
      "description": "Public-safe patterns for linking PlatPhorm services while preserving ownership, auth boundaries, and honest handoffs.",
      "entryIds": [
        "integration-contract-cards",
        "public-private-sorting",
        "trust-but-verify-buttons",
        "source-map-before-summary",
        "socratic-eval-prompts",
        "misconception-map",
        "tool-dry-run",
        "abstention-design",
        "memory-hygiene"
      ]
    },
    {
      "id": "prompt-reliability",
      "title": "Prompt reliability",
      "description": "Practical habits for getting less brittle model behavior before adding heavier tooling.",
      "entryIds": [
        "schema-first-output",
        "semantic-diff",
        "socratic-eval-prompts",
        "short-system-prompts",
        "negative-space",
        "few-shot-format",
        "context-rot",
        "temperature",
        "self-consistency"
      ]
    },
    {
      "id": "interpretability-fieldwork",
      "title": "Interpretability fieldwork",
      "description": "Ways to inspect internal signals and move from pretty explanations to causal evidence.",
      "entryIds": [
        "logprobs",
        "feature-probing",
        "sae",
        "activation-patching",
        "logit-lens",
        "attention-viz"
      ]
    },
    {
      "id": "verification-discipline",
      "title": "Verification discipline",
      "description": "Small rituals that keep AI-assisted work tied to evidence, tests, and explicit uncertainty.",
      "entryIds": [
        "inspect-one-claim",
        "retrieval-relevance",
        "artifact-questions",
        "source-map-before-summary",
        "citation-triangulation",
        "definition-vs-proof",
        "dictionary-backed-verification",
        "confidence-buckets",
        "receipts",
        "counter-evidence",
        "memory-hygiene",
        "refusal-fixtures",
        "token-counter"
      ]
    },
    {
      "id": "operator-safety",
      "title": "Operator safety",
      "description": "Patterns for agents that can act, route work, abstain, or spend extra verification budget.",
      "entryIds": [
        "first-safe-agent-plan",
        "public-private-sorting",
        "tool-dry-run",
        "integration-contract-cards",
        "abstention-design",
        "latency-budget",
        "model-routing",
        "red-team-mutants",
        "eval-sandwich"
      ]
    }
  ],
  "insightLabModules": [
    {
      "id": "logprobs",
      "kind": "logprobs",
      "entryId": "logprobs",
      "eyebrow": "Uncertainty trace",
      "title": "The sentence is fluent. The token path may not be.",
      "aha": "A low-margin token is where the model nearly chose a different world.",
      "explanation": "This toy trace turns a polished answer into token confidence. The cold tokens are where a reviewer should slow down first.",
      "operatorMove": "Read names, dates, citations, and refusal-boundary words with the token margin visible.",
      "tokens": [
        {
          "token": "The",
          "confidence": 0.98,
          "alternative": "A"
        },
        {
          "token": "paper",
          "confidence": 0.81,
          "alternative": "study"
        },
        {
          "token": "was",
          "confidence": 0.95,
          "alternative": "is"
        },
        {
          "token": "published",
          "confidence": 0.72,
          "alternative": "released"
        },
        {
          "token": "in",
          "confidence": 0.91,
          "alternative": "around"
        },
        {
          "token": "2024",
          "confidence": 0.53,
          "alternative": "2023"
        },
        {
          "token": "by",
          "confidence": 0.69,
          "alternative": "from"
        },
        {
          "token": "OpenAI",
          "confidence": 0.56,
          "alternative": "Anthropic"
        }
      ],
      "stages": [
        "Decoded answer",
        "Token margin",
        "Reviewer target"
      ]
    },
    {
      "id": "receipts",
      "kind": "receipts",
      "entryId": "receipts",
      "eyebrow": "Evidence discipline",
      "title": "Claims become safer when each one has a handle.",
      "aha": "Unsupported prose can sound identical to supported prose until you force receipts into view.",
      "explanation": "The animation pairs each claim with the kind of proof a human can inspect. The point is not citation theater; it is making unsupported load-bearing text visible.",
      "operatorMove": "Require one receipt per important claim before accepting a summary, diagnosis, or recommendation.",
      "claims": [
        {
          "claim": "Route compliance is complete.",
          "receipt": "Route inventory plus smoke result"
        },
        {
          "claim": "The entry count is 17.",
          "receipt": "Derived from lib/entries.ts"
        },
        {
          "claim": "Report generation is protected.",
          "receipt": "401 without PLATPHORM_API_KEY"
        }
      ],
      "stages": [
        "Claim",
        "Receipt",
        "Decision"
      ]
    },
    {
      "id": "counter-evidence",
      "kind": "counter-evidence",
      "entryId": "counter-evidence",
      "eyebrow": "Confidence check",
      "title": "Confidence is cheaper before the answer gets defended.",
      "aha": "Ask for the best objection early and the model often reveals the missing constraint.",
      "explanation": "This pattern makes the model argue against its first draft before assigning confidence, which makes the confidence score less ornamental.",
      "operatorMove": "Do not ask for confidence until the model has named what could falsify the answer.",
      "stages": [
        "Draft",
        "Counter-evidence",
        "Calibrated answer"
      ]
    },
    {
      "id": "temperature",
      "kind": "temperature",
      "entryId": "temperature",
      "eyebrow": "Sampling control",
      "title": "The creativity dial changes spread, not truth.",
      "aha": "High temperature can be great for options and terrible for extraction because it rewards variance.",
      "explanation": "The distributions below use the same candidate tokens. The only change is how much the sampler is allowed to wander.",
      "operatorMove": "Use low temperature when correctness has one target; raise it when diversity is the target.",
      "stages": [
        "Extraction",
        "Drafting",
        "Brainstorming"
      ]
    },
    {
      "id": "context-position",
      "kind": "context-position",
      "entryId": "context-rot",
      "eyebrow": "Prompt topology",
      "title": "The middle can be technically present and practically lost.",
      "aha": "Moving one critical fact from the middle to the edge can change whether the model uses it.",
      "explanation": "Long-context behavior often favors the beginning and end. This demo shows why constraints should live at the edges, not buried in filler.",
      "operatorMove": "Place the task contract first and repeat the highest-risk constraint at the end.",
      "stages": [
        "Buried fact",
        "Edge facts",
        "Safer prompt"
      ]
    },
    {
      "id": "attention-routing",
      "kind": "attention-routing",
      "entryId": "attention-viz",
      "eyebrow": "Routing map",
      "title": "Some heads act like tiny routing specialists.",
      "aha": "The interesting question is not whether attention is pretty; it is whether a routing pattern survives perturbation.",
      "explanation": "The animated lines are a toy view of heads tracking paired tokens. Real value comes from testing whether the pattern matters for behavior.",
      "operatorMove": "Use attention maps to form hypotheses, then perturb the prompt or run a causal check.",
      "stages": [
        "Tokens",
        "Routing",
        "Hypothesis"
      ]
    }
  ],
  "fieldGuidePlaybooks": [
    {
      "id": "hallucination-triage",
      "title": "Hallucination triage",
      "problem": "A model produced a confident answer and nobody knows whether the weak point is retrieval, reasoning, or source support.",
      "outcome": "A reviewer can identify which claims are supported, which claims need receipts, and which answer parts should be withheld.",
      "entryIds": [
        "logprobs",
        "retrieval-relevance",
        "receipts",
        "citation-triangulation",
        "confidence-buckets"
      ],
      "steps": [
        {
          "label": "Locate fragile spans",
          "action": "Highlight names, dates, numbers, citations, and low-margin tokens before reading the answer as prose.",
          "aha": "Hallucinations often hide where fluency is highest but token certainty is thinnest."
        },
        {
          "label": "Separate retrieval from generation",
          "action": "Mark each retrieved chunk as direct support, background, contradiction, or irrelevant.",
          "aha": "Bad context can make a good model sound wrong with confidence."
        },
        {
          "label": "Attach receipts",
          "action": "Force each important claim to point to a source, row, command, calculation, trace id, or assumption.",
          "aha": "The unsupported claim does not vanish; it becomes visible enough to reject."
        },
        {
          "label": "Decide the confidence bucket",
          "action": "Assign high, medium, low, or unknown based on evidence quality and contradiction level.",
          "aha": "Confidence matters when it changes the next action."
        }
      ]
    },
    {
      "id": "prompt-change-control",
      "title": "Prompt change control",
      "problem": "A system prompt needs improvement, but every wording edit risks changing refusal, format, or evidence behavior.",
      "outcome": "The prompt change ships with a semantic diff, targeted fixtures, and a clear before/during/after eval record.",
      "entryIds": [
        "short-system-prompts",
        "semantic-diff",
        "eval-sandwich",
        "red-team-mutants",
        "refusal-fixtures"
      ],
      "steps": [
        {
          "label": "Shrink the contract",
          "action": "Separate durable role, hard boundary, output contract, and escalation rule from task-specific detail.",
          "aha": "A smaller system prompt is not weaker; it is easier to audit."
        },
        {
          "label": "Diff the meaning",
          "action": "List new obligations, removed constraints, softened verbs, and examples that imply new rules.",
          "aha": "A one-word modal change can quietly become a policy change."
        },
        {
          "label": "Run the eval sandwich",
          "action": "Baseline before, targeted fixture during, broad regression after.",
          "aha": "The middle eval catches drift while the edit is still cheap."
        },
        {
          "label": "Mutate the boundary",
          "action": "Test harmless variants that preserve intent while changing tone, order, language, and framing.",
          "aha": "A boundary that only catches the obvious phrasing is not a boundary."
        }
      ]
    },
    {
      "id": "agent-action-gate",
      "title": "Agent action gate",
      "problem": "An agent can call tools, but the operator needs confidence before it mutates, publishes, replays, deletes, or spends.",
      "outcome": "Every action moves through preview, inspect, authorize, execute, and verify without hiding protected states.",
      "entryIds": [
        "tool-dry-run",
        "abstention-design",
        "latency-budget",
        "model-routing",
        "memory-hygiene"
      ],
      "steps": [
        {
          "label": "Preview the action",
          "action": "Require target ids, arguments, expected effect, refusal condition, and rollback notes.",
          "aha": "Permission to plan is not permission to execute; the preview is where unsafe scope becomes inspectable."
        },
        {
          "label": "Respect blocked states",
          "action": "Return unknown, partial, protected-required, or needs-review when evidence or authorization is missing.",
          "aha": "A designed stop is better than a graceful guess because it preserves trust and gives the operator a next move."
        },
        {
          "label": "Spend checks by risk",
          "action": "Wake up extra verification when impact is high, evidence is weak, or the action is protected.",
          "aha": "Latency can be evidence-driven instead of uniformly expensive."
        },
        {
          "label": "Verify after execution",
          "action": "Check the actual changed state, not only the tool's success response.",
          "aha": "The world, not the model, gets the final vote, so post-action evidence is part of the action itself."
        }
      ]
    }
  ],
  "failureCaseStudies": [
    {
      "id": "source-shaped-hallucination",
      "title": "The source-shaped hallucination",
      "setup": "A model summarizes a report and includes a link beside every claim.",
      "failure": "The links exist, but two citations point to documents that discuss the topic without supporting the exact sentence.",
      "hiddenSignal": "The unsupported claims are entity/date claims with weak token margins and broad source references.",
      "repair": "Use receipts per claim, then triangulate the high-impact facts with independent sources before publishing.",
      "aha": "A citation beside a sentence is not the same thing as support under the sentence.",
      "entryIds": [
        "receipts",
        "citation-triangulation",
        "logprobs"
      ]
    },
    {
      "id": "middle-context-loss",
      "title": "The buried constraint",
      "setup": "A long prompt includes a critical policy exception in the middle of retrieved context.",
      "failure": "The answer follows the opening task and closing format while ignoring the exception.",
      "hiddenSignal": "The missed fact was technically present but surrounded by lower-value context.",
      "repair": "Move the task contract to the opening, repeat the exception at the end, and rank retrieved chunks before generation.",
      "aha": "Presence in context is not the same thing as usable salience.",
      "entryIds": [
        "context-rot",
        "retrieval-relevance",
        "schema-first-output"
      ]
    },
    {
      "id": "tool-call-overreach",
      "title": "The tool call that did too much",
      "setup": "An agent is asked to clean a set of records and calls a bulk mutation tool.",
      "failure": "The selector is broader than the user intended and changes records outside the target set.",
      "hiddenSignal": "The model never previewed target ids or stated a rollback condition.",
      "repair": "Add a dry-run gate, require explicit target ids, and make protected-required a first-class state.",
      "aha": "Tool safety starts before execution, not after the audit log catches damage.",
      "entryIds": [
        "tool-dry-run",
        "abstention-design",
        "latency-budget"
      ]
    },
    {
      "id": "prompt-edit-regression",
      "title": "The helpful prompt edit that moved the boundary",
      "setup": "A prompt is edited to make answers friendlier and less formal.",
      "failure": "The model starts complying with requests it previously redirected because the new examples imply looser policy.",
      "hiddenSignal": "The text diff is small, but the semantic diff changes tone, authority, and refusal posture.",
      "repair": "Run a semantic diff, then use refusal fixtures and harmless mutants before shipping.",
      "aha": "Style examples can become behavioral instructions if you do not test the boundary.",
      "entryIds": [
        "semantic-diff",
        "refusal-fixtures",
        "red-team-mutants"
      ]
    }
  ],
  "ahaLadder": [
    {
      "id": "answer-to-signal",
      "title": "From answer to signal",
      "before": "Read the model's sentence and judge whether it sounds plausible.",
      "after": "Inspect token margins, retrieved evidence, receipts, and contradiction before judging.",
      "operatorQuestion": "Where would this answer break first?"
    },
    {
      "id": "prompt-to-contract",
      "title": "From prompt to contract",
      "before": "Write instructions until the behavior feels described.",
      "after": "Define the output schema, failure states, hard boundary, and test fixtures.",
      "operatorQuestion": "What is the model allowed to leave blank?"
    },
    {
      "id": "tool-to-action",
      "title": "From tool to action",
      "before": "Let the agent call a tool when it appears to understand the task.",
      "after": "Preview arguments, inspect target ids, authorize mutation, execute, then verify changed state.",
      "operatorQuestion": "What would stop this action before it runs?"
    },
    {
      "id": "confidence-to-decision",
      "title": "From confidence to decision",
      "before": "Ask the model for a percentage and decide whether it feels high enough.",
      "after": "Bucket confidence by evidence quality, conflict level, and downstream impact.",
      "operatorQuestion": "What does this confidence label change?"
    }
  ],
  "focusMode": {
    "endpoint": "/api/v1/focus-mode",
    "frameCount": 6,
    "frames": [
      {
        "id": "shared-terms",
        "eyebrow": "Start here",
        "title": "Name the term before the trick",
        "takeaway": "Model behavior is hard to inspect when the key vocabulary is unstable.",
        "body": "Open with the words that matter: retrieval, receipt, confidence bucket, dry run, abstention, provenance. Once the terms are shared, the demo becomes an evidence exercise instead of a vocabulary scramble.",
        "entryIds": [
          "plain-then-precise",
          "term-first-fieldwork",
          "dictionary-backed-verification"
        ],
        "dictionaryTerm": "retrieval relevance",
        "notesPrompt": "Which word in today's demo felt familiar but turned out to need a stricter definition?",
        "aha": "The glossary is not background material. It is part of the operating system for the work."
      },
      {
        "id": "artifact-first",
        "eyebrow": "Inspection",
        "title": "Put an artifact on screen",
        "takeaway": "The room needs something concrete to inspect: an answer, citation, tool preview, or note.",
        "body": "A good technical walkthrough has a visible object. Point at the fragile claim, irrelevant retrieved chunk, broad selector, or missing receipt before summarizing the system.",
        "entryIds": [
          "artifact-questions",
          "inspect-one-claim",
          "explain-inspect-repair-loop",
          "receipts"
        ],
        "dictionaryTerm": "receipt",
        "notesPrompt": "What exact artifact made you change your mind about the model output?",
        "aha": "Evidence has to be visible before judgment can become repeatable."
      },
      {
        "id": "dry-run-action",
        "eyebrow": "Agents",
        "title": "Preview action before authority",
        "takeaway": "A model that can mutate state needs a dry run, target ids, stop conditions, and verification.",
        "body": "Use a tool-call example where the selector is too broad. Mark what would change, who must approve it, and what proof is needed after the tool runs.",
        "entryIds": [
          "first-safe-agent-plan",
          "public-private-sorting",
          "tool-dry-run",
          "integration-contract-cards"
        ],
        "dictionaryTerm": "dry run",
        "notesPrompt": "What would stop this tool call before it touches real state?",
        "aha": "Permission to explain a tool call is not permission to execute it."
      },
      {
        "id": "abstention-branch",
        "eyebrow": "Reliability",
        "title": "Make stopping a valid answer",
        "takeaway": "Unknown, partial, protected-required, and needs-review states keep bad certainty from becoming product behavior.",
        "body": "Compare two schemas: one that forces every field to be filled, and one that allows useful absence states. Decide which one prevents invented data and why.",
        "entryIds": [
          "readiness-red-yellow-green",
          "abstention-design",
          "schema-first-output"
        ],
        "dictionaryTerm": "abstention",
        "notesPrompt": "Where did the model need an honest stop state instead of a smoother sentence?",
        "aha": "A graceful stop can be the most helpful output in the room."
      },
      {
        "id": "notes-to-glossary",
        "eyebrow": "Capture",
        "title": "Turn repeated confusion into better tools",
        "takeaway": "Repeated confusion is a product signal, not an interruption.",
        "body": "Capture the phrase that caused confusion in Notes. If the phrase repeats, move it into a human-reviewed Dictionary candidate and add a notebook exercise around it.",
        "entryIds": [
          "definition-vs-proof",
          "note-to-definition-pipeline",
          "misconception-map"
        ],
        "dictionaryTerm": "provenance",
        "notesPrompt": "What phrase should become a shared glossary candidate after this walkthrough?",
        "aha": "The field notes are generating the next version of the shared vocabulary."
      },
      {
        "id": "self-quiz-transfer",
        "eyebrow": "Retention",
        "title": "End with recall, artifact, transfer",
        "takeaway": "An insight is useful when it can be named, used on an artifact, and transferred to another workflow.",
        "body": "Close with three questions: what is the concept, where does it appear in this output, and where would you look for the same pattern in a different workflow?",
        "entryIds": [
          "aha-from-mistake",
          "self-quiz-cards",
          "aha-checkpoints"
        ],
        "dictionaryTerm": "prompt fixture",
        "notesPrompt": "Write one transfer question that would catch shallow memorization.",
        "aha": "The final question should prove the habit moved beyond this frame."
      }
    ]
  },
  "integrations": {
    "integrations": [
      {
        "id": "dictionary",
        "name": "PlatPhorm Dictionary",
        "url": "https://dictionary.platphormnews.com",
        "purpose": "Public terminology, definitions, provenance lookup, search, datasets, term graph, and MCP discovery.",
        "publicReads": [
          "Approved public terms",
          "Dictionary search",
          "OpenAPI and llms discovery",
          "Term graph and provenance lookup",
          "Read-only MCP introspection"
        ],
        "protectedBoundary": "Moderation, import, admin, private submissions, audit logs, protected reports, model-assisted moderation, registry mutation, and destructive actions require PLATPHORM_API_KEY when enforcement is enabled.",
        "handoffActions": [
          {
            "label": "Open Dictionary",
            "href": "https://dictionary.platphormnews.com",
            "description": "Browse the public dictionary surface."
          },
          {
            "label": "Search terms",
            "href": "https://dictionary.platphormnews.com/api/v1/search?q=retrieval&limit=5",
            "description": "Use the public search API for vocabulary checks."
          },
          {
            "label": "Review trust policy",
            "href": "https://dictionary.platphormnews.com/.well-known/trust.json",
            "description": "Inspect the public/protected boundary before handoff."
          }
        ],
        "notebookUse": "This notebook links concepts to Dictionary as concept receipts and glossary anchors; it does not publish definitions on the user's behalf."
      },
      {
        "id": "notes",
        "name": "PlatPhorm Notes",
        "url": "https://notes.platphormnews.com",
        "purpose": "Public learning notepad for note enrichment, terminology detection, Dictionary lookup, and human-approved definition staging.",
        "publicReads": [
          "App shell and discovery files",
          "Public templates",
          "Term detection previews",
          "Note analysis previews",
          "Workflow templates and integration status"
        ],
        "protectedBoundary": "No visitor key entry. Backend calls to Dictionary, Docs, OpenContent, Sheets, Phorm, SVG, and other PlatPhorm services require PLATPHORM_API_KEY server-side.",
        "handoffActions": [
          {
            "label": "Open Notes",
            "href": "https://notes.platphormnews.com",
            "description": "Capture observations and terminology questions."
          },
          {
            "label": "Read Notes index",
            "href": "https://notes.platphormnews.com/llms-index.json",
            "description": "Inspect public templates, workflows, and tools."
          },
          {
            "label": "Review trust policy",
            "href": "https://notes.platphormnews.com/.well-known/trust.json",
            "description": "Confirm public reads and protected backend boundaries."
          }
        ],
        "notebookUse": "This notebook gives readers prompts and observation formats to use in Notes; it does not store note bodies or stage submissions directly."
      }
    ],
    "dictionaryTermBridges": [
      {
        "term": "retrieval relevance",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=retrieval%20relevance&limit=5",
        "entryIds": [
          "retrieval-relevance",
          "glossary-before-demo"
        ],
        "fieldUse": "Define retrieval and relevance before scoring chunks.",
        "notePrompt": "What retrieved chunk looked authoritative but did not answer the question?"
      },
      {
        "term": "receipt",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=receipt&limit=5",
        "entryIds": [
          "receipts",
          "dictionary-backed-verification"
        ],
        "fieldUse": "Treat a source, command, row, calculation, or assumption as a claim handle.",
        "notePrompt": "Which sentence in the answer needs a receipt before you would reuse it?"
      },
      {
        "term": "dry run",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=dry%20run&limit=5",
        "entryIds": [
          "tool-dry-run",
          "integration-contract-cards"
        ],
        "fieldUse": "Show the action plan before any tool mutates state.",
        "notePrompt": "What target ids, selectors, or rollback notes were missing from the tool preview?"
      },
      {
        "term": "abstention",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=abstention&limit=5",
        "entryIds": [
          "abstention-design",
          "confidence-buckets"
        ],
        "fieldUse": "Make unknown, partial, protected-required, and needs-review legitimate outcomes.",
        "notePrompt": "Where should the model have stopped instead of filling the answer?"
      },
      {
        "term": "prompt fixture",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=prompt%20fixture&limit=5",
        "entryIds": [
          "refusal-fixtures",
          "socratic-eval-prompts"
        ],
        "fieldUse": "Keep examples that should pass, refuse, redirect, or require more evidence.",
        "notePrompt": "Which prompt should become a fixture because it revealed a boundary?"
      },
      {
        "term": "provenance",
        "href": "https://dictionary.platphormnews.com/api/v1/search?q=provenance&limit=5",
        "entryIds": [
          "dictionary-provenance-check",
          "citation-triangulation"
        ],
        "fieldUse": "Ask where a term or fact came from before relying on it.",
        "notePrompt": "What source or scope would change how you teach this definition?"
      }
    ],
    "notesWorkflowBridges": [
      {
        "id": "observe-before-judging",
        "title": "Observe before judging",
        "notesWorkflow": "Readers capture what they saw, expected, think it means, and need defined.",
        "dictionaryHandoff": "Repeated undefined phrases become Dictionary candidate definitions after review.",
        "notebookEntries": [
          "notes-as-observation-log",
          "misconception-map"
        ],
        "fieldPrompt": "Write one observation from the demo that changed what you would inspect next."
      },
      {
        "id": "term-detection-review",
        "title": "Term detection review",
        "notesWorkflow": "Paste a short reflection and preview which technical terms need definitions.",
        "dictionaryHandoff": "Open Dictionary search for each high-confusion term before publishing a new definition.",
        "notebookEntries": [
          "term-first-fieldwork",
          "glossary-before-demo"
        ],
        "fieldPrompt": "Which term appeared with two different meanings?"
      },
      {
        "id": "definition-staging",
        "title": "Definition staging",
        "notesWorkflow": "A rough explanation is staged as a draft, not treated as approved.",
        "dictionaryHandoff": "Human review decides whether the draft becomes a public Dictionary term.",
        "notebookEntries": [
          "note-to-definition-pipeline",
          "human-approval-queue"
        ],
        "fieldPrompt": "What would you change before this definition becomes shared technical language?"
      },
      {
        "id": "self-quiz-recall",
        "title": "Self-quiz recall",
        "notesWorkflow": "Create recall, artifact, and transfer questions from the current entries.",
        "dictionaryHandoff": "Definitions become answer keys only after the concept scope is clear.",
        "notebookEntries": [
          "self-quiz-cards",
          "concept-ladder"
        ],
        "fieldPrompt": "What is the transfer question that proves you can use this idea elsewhere?"
      }
    ],
    "integrationAhaMoments": [
      "Dictionary stabilizes shared terminology; Notes captures repeated confusion; this notebook turns both into repeatable operating habits.",
      "A public-safe handoff is still useful when it is honest about what it cannot mutate.",
      "The best integration is not a button. It is a clear ownership boundary plus a next action."
    ],
    "policy": "Dictionary and Notes integrations are public-read handoffs from this site. Publishing, ingestion, moderation, workflow execution, and protected reporting remain PLATPHORM_API_KEY-gated on the owning service."
  },
  "platformLiteracy": {
    "source": {
      "rootUrl": "https://platphormnews.com",
      "networkGraph": "https://platphormnews.com/api/network/graph",
      "mcpManifest": "https://platphormnews.com/.well-known/mcp.json",
      "agentPolicy": "https://platphormnews.com/.well-known/agent-policy.json",
      "robots": "https://platphormnews.com/robots.txt",
      "llmsIndex": "https://platphormnews.com/llms-index.json",
      "apiDocs": "https://platphormnews.com/api/docs",
      "sourceNotes": [
        "Root MCP manifest identifies platphorm-root as the public DMZ network root.",
        "Root network graph publishes site, node, edge, source, category, compliance, and trusted-domain metadata.",
        "Root robots policy allows public LLM discovery paths and blocks admin/private/protected paths plus token/key/secret query patterns.",
        "Root JSON-LD exposes organization, website search, navigation, and FAQ identity data."
      ]
    },
    "tips": [
      {
        "id": "public-dmz",
        "title": "Public DMZ means safe read-only front door",
        "surface": "Root MCP manifest and trust policy",
        "sourceUrl": "https://platphormnews.com/.well-known/mcp.json",
        "plainLanguage": "Think of the public DMZ like a public lobby. Anyone can ask where things are, but they cannot unlock private rooms, edit records, or trigger protected work.",
        "operator": "The root site publishes public discovery, network graph, stories, route compliance, and MCP introspection while reserving sync, validation, reports, and policy updates for protected actions.",
        "realWorldView": "Your job is to check that the front desk gives useful directions without accidentally becoming an admin panel.",
        "aha": "Public does not mean powerful. Public means safely inspectable.",
        "fieldMove": "Sort five actions into public read or protected mutation before looking at any API response.",
        "safeBoundary": "Do not test destructive, private, protected, credential, admin, or mutation paths without explicit authorization.",
        "entryIds": [
          "integration-contract-cards",
          "abstention-design"
        ]
      },
      {
        "id": "network-graph",
        "title": "The network graph is the map of the city",
        "surface": "GET /api/network/graph",
        "sourceUrl": "https://platphormnews.com/api/network/graph",
        "plainLanguage": "A website network is like a city. The graph tells you what buildings exist and how roads connect them.",
        "operator": "The root graph reports sites, nodes, edges, sources, categories, route compliance, discovery compliance, and trusted domain status.",
        "realWorldView": "A graph helps you check coverage: which sites are trusted, which surfaces are discoverable, and which claims need source-backed evidence.",
        "aha": "Discovery is not guessing URLs. Discovery is reading the map the platform publishes.",
        "fieldMove": "Show one graph count, then ask what evidence would prove whether a site is in or out of scope.",
        "safeBoundary": "Stay inside trusted domains and published discovery routes. Do not crawl arbitrary user-provided URLs.",
        "entryIds": [
          "dictionary-provenance-check",
          "memory-hygiene"
        ]
      },
      {
        "id": "robots-llms",
        "title": "robots.txt and llms files teach crawler manners",
        "surface": "robots.txt, llms.txt, llms-full.txt, llms-index.json",
        "sourceUrl": "https://platphormnews.com/robots.txt",
        "plainLanguage": "robots.txt is a hallway sign for crawlers. llms files are a study guide for AI systems.",
        "operator": "The root robots policy allows public discovery files and graph routes for LLM crawlers while blocking admin, private, protected, auth, cron, webhook, and secret-query paths.",
        "realWorldView": "Good automation respects the published crawl lanes. Ignoring them is not clever; it is unsafe and low-signal.",
        "aha": "The safest crawler is the one that reads instructions before touching the site.",
        "fieldMove": "Mark which listed routes are safe to inspect and which are clear stop signs.",
        "safeBoundary": "Never put tokens, keys, or secrets into URLs, traces, screenshots, feeds, or public artifacts.",
        "entryIds": [
          "glossary-before-demo",
          "integration-contract-cards"
        ]
      },
      {
        "id": "mcp-toolbox",
        "title": "MCP is a toolbox, not a permission slip",
        "surface": ".well-known/mcp.json and /api/mcp",
        "sourceUrl": "https://platphormnews.com/.well-known/mcp.json",
        "plainLanguage": "MCP lists tools an AI client can ask for, like a toolbox label. The label does not mean every tool is safe for every person to use.",
        "operator": "The root manifest exposes JSON-RPC methods, public tools, protected tools, resources, prompts, trace headers, and the PLATPHORM_API_KEY boundary.",
        "realWorldView": "Read tools/list and resources/list first. Confirm whether a tool is public read-only or protected before designing any workflow.",
        "aha": "Tool discovery comes before tool execution.",
        "fieldMove": "Inspect a tool list and flag which names sound mutating before reading the protected list.",
        "safeBoundary": "Do not call sync, refresh, ingestion, reporting, or policy-update tools unless authorized and key-gated.",
        "entryIds": [
          "tool-dry-run",
          "human-approval-queue"
        ]
      },
      {
        "id": "openapi-contract",
        "title": "OpenAPI is the menu with ingredients listed",
        "surface": "/api/docs and /openapi.yaml",
        "sourceUrl": "https://platphormnews.com/api/docs",
        "plainLanguage": "An API doc is a menu. It tells you what you can ask for, what parameters it accepts, and what shape the answer should have.",
        "operator": "The root API documentation covers stories, search, sources, network APIs, network MCP, evidence, trustops, searchops, agentops, public contract, feeds, and discovery routes.",
        "realWorldView": "A contract lets you test behavior without guessing. You can verify route shape, auth requirements, and public-safe responses.",
        "aha": "Guessing endpoint behavior is amateur hour; reading the contract is how experts move fast safely.",
        "fieldMove": "Pick one endpoint and predict query params, success shape, and protected boundary before calling it.",
        "safeBoundary": "Use read-only endpoints for practice. Treat POST, sync, ingestion, and reporting routes as protected unless explicitly documented otherwise.",
        "entryIds": [
          "schema-first-output",
          "socratic-eval-prompts"
        ]
      },
      {
        "id": "jsonld-identity",
        "title": "JSON-LD is the site's ID card",
        "surface": "Homepage JSON-LD",
        "sourceUrl": "https://platphormnews.com",
        "plainLanguage": "JSON-LD is structured data that tells search engines and agents who the site is, what it publishes, and what actions it supports.",
        "operator": "The root homepage publishes organization, website search action, navigation, and FAQ structured data for public identity and discoverability.",
        "realWorldView": "Structured data is a claim surface. Compare it with live routes and policies to catch stale identity, stale navigation, or unsafe promises.",
        "aha": "A page can speak to humans in HTML and to machines in JSON-LD at the same time.",
        "fieldMove": "Find one human sentence and one JSON-LD claim that should agree.",
        "safeBoundary": "Do not treat structured data as secret or authority by itself; verify with the corresponding public route.",
        "entryIds": [
          "receipts",
          "citation-triangulation"
        ]
      },
      {
        "id": "rss-sitemap",
        "title": "RSS tells what changed; sitemaps tell what exists",
        "surface": "RSS, Atom, sitemap, sitemap index",
        "sourceUrl": "https://platphormnews.com/rss.xml",
        "plainLanguage": "RSS is the update stream. A sitemap is the table of contents. Together they help people and machines find new and existing pages.",
        "operator": "The root publishes RSS/feed/Atom and several sitemap variants, including network and full sitemap surfaces, with robots pointers.",
        "realWorldView": "Feeds and sitemaps are low-risk coverage tools. They reveal intended public pages without probing private paths.",
        "aha": "The public site tells you where to look if you start with the sitemap instead of guessing.",
        "fieldMove": "Compare one RSS item with one sitemap URL and name which question each file answers.",
        "safeBoundary": "Use published sitemaps instead of brute-force path discovery.",
        "entryIds": [
          "retrieval-relevance",
          "misconception-map"
        ]
      },
      {
        "id": "agent-policy",
        "title": "Agent policy tells bots how to behave",
        "surface": ".well-known/agent-policy.json",
        "sourceUrl": "https://platphormnews.com/.well-known/agent-policy.json",
        "plainLanguage": "Agent policy is the operating boundary for AI clients: what they can read, what needs a key, and what data must stay private.",
        "operator": "The root policy names public access surfaces, supported client classes, PLATPHORM_API_KEY requirements, trace propagation, JA4 redaction, and no-private-data rules.",
        "realWorldView": "Before running any automated inspection, prove your agent obeys the policy and can stop at protected boundaries.",
        "aha": "A well-behaved agent is safer because it knows where not to go.",
        "fieldMove": "Design a crawler that can explain why it skipped a protected path.",
        "safeBoundary": "No secrets, cookies, raw IP addresses, raw JA4 digests, private traces, or private audit details in public reports.",
        "entryIds": [
          "abstention-design",
          "notes-as-observation-log"
        ]
      },
      {
        "id": "trace-context",
        "title": "Trace headers are the breadcrumb trail",
        "surface": "MCP manifest and agent policy trace fields",
        "sourceUrl": "https://platphormnews.com/.well-known/agent-policy.json",
        "plainLanguage": "Trace headers are like numbered sticky notes that help you follow one request as it moves between services.",
        "operator": "Root policy accepts traceparent, tracestate, X-PlatPhorm-Trace-Id, and propagates safe PlatPhorm trace/request/source/target headers.",
        "realWorldView": "Traceability helps debug cross-site behavior, but secret baggage must never ride along.",
        "aha": "Observability is useful only when it does not leak the thing it observes.",
        "fieldMove": "Draw a three-service request path and label which trace fields travel forward.",
        "safeBoundary": "Never put authorization, API keys, cookies, session tokens, or raw private payloads into trace state or baggage.",
        "entryIds": [
          "memory-hygiene",
          "integration-contract-cards"
        ]
      },
      {
        "id": "source-backed-status",
        "title": "Status should say how it knows",
        "surface": "Network graph and compliance payloads",
        "sourceUrl": "https://platphormnews.com/api/network/graph",
        "plainLanguage": "A status card is better when it tells you where the number came from, not just whether it is green.",
        "operator": "Root discovery surfaces label sources such as static manifest, MCP registry, sitemap index, declared route spec, stale markers, confidence, and checkedAt timestamps.",
        "realWorldView": "Source labels let you separate current evidence from stale, degraded, inferred, or declared-only status.",
        "aha": "Green without evidence is decoration. Green with source and time is operational signal.",
        "fieldMove": "Compare two green statuses and decide which one has enough evidence to trust.",
        "safeBoundary": "Do not convert degraded or declared-only status into a claim of live success.",
        "entryIds": [
          "confidence-buckets",
          "dictionary-provenance-check"
        ]
      }
    ],
    "skillRampLevels": [
      {
        "id": "level-1",
        "label": "First-pass reader",
        "readerCan": "Explain the difference between public read, protected action, and private data.",
        "practice": "Sort routes from robots.txt into safe-to-read and stop-sign groups."
      },
      {
        "id": "level-2",
        "label": "Careful operator",
        "readerCan": "Use sitemaps, RSS, llms files, OpenAPI, and JSON-LD to inspect a site without guessing.",
        "practice": "Build a source-backed checklist for one public surface."
      },
      {
        "id": "level-3",
        "label": "Agent workflow designer",
        "readerCan": "Read MCP tools/resources/prompts and design a public-safe workflow with explicit stop states.",
        "practice": "Write a dry-run plan for a read-only MCP inspection."
      },
      {
        "id": "level-4",
        "label": "Real-world operator",
        "readerCan": "Audit public automation behavior while respecting trust policy, robots policy, auth boundaries, trace redaction, and no-secret rules.",
        "practice": "Produce a report that says what was inspected, what was skipped, why it was skipped, and what evidence supports each conclusion."
      }
    ],
    "policy": "These tips teach public-safe inspection and careful automation. They do not authorize private probing, credential testing, destructive actions, or protected workflow execution."
  },
  "researchTrends": {
    "service": "ai-insights-for-humans",
    "generatedAt": "2026-07-21T08:35:50.365Z",
    "purpose": "Source-backed research digest and public-safe demonstrations for inspecting how AI systems reason, loop, call tools, use webhooks, and respond to portable prompt contracts.",
    "evidenceBoundary": "The content explains observable signals and source-backed trends. It does not expose hidden provider chain-of-thought, private model internals, or execute protected tools.",
    "sources": [
      {
        "id": "anthropic-circuit-tracing",
        "title": "Tracing the thoughts of a large language model",
        "publisher": "Anthropic",
        "published": "2025",
        "kind": "lab_blog",
        "url": "https://www.anthropic.com/news/tracing-thoughts-language-model",
        "signal": "Attribution graphs and circuit tracing are turning model internals into inspectable pathways rather than mystery boxes.",
        "readerTakeaway": "We cannot read private thoughts, but we can inspect partial evidence about which features and paths influenced an answer."
      },
      {
        "id": "anthropic-attribution-graphs",
        "title": "Attribution graph methods",
        "publisher": "Transformer Circuits / Anthropic",
        "published": "2025",
        "kind": "paper",
        "url": "https://transformer-circuits.pub/2025/attribution-graphs/methods.html",
        "signal": "Mechanistic interpretability is becoming a reproducible workflow: build graph, localize path, test causal contribution.",
        "readerTakeaway": "A beautiful graph is only a hypothesis until an intervention changes model behavior."
      },
      {
        "id": "react-paper",
        "title": "ReAct: Synergizing reasoning and acting in language models",
        "publisher": "arXiv",
        "published": "2022",
        "kind": "paper",
        "url": "https://arxiv.org/abs/2210.03629",
        "signal": "The reason-act-observe rhythm remains the clearest first-pass model for agent loops.",
        "readerTakeaway": "An agent is not magic autonomy. It is a loop with observations, decisions, actions, and checks."
      },
      {
        "id": "anthropic-effective-agents",
        "title": "Building effective agents",
        "publisher": "Anthropic Engineering",
        "published": "2024",
        "kind": "lab_blog",
        "url": "https://www.anthropic.com/engineering/building-effective-agents",
        "signal": "Useful agents are usually simple workflows with clear tool boundaries before they are open-ended autonomy.",
        "readerTakeaway": "Start with a visible workflow, then let the model choose inside well-labeled rails."
      },
      {
        "id": "anthropic-context-engineering",
        "title": "Effective context engineering for AI agents",
        "publisher": "Anthropic Engineering",
        "published": "2025",
        "kind": "lab_blog",
        "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents",
        "signal": "The practical prompt surface is the whole context stack: instructions, tools, memory, retrieved files, and stop rules.",
        "readerTakeaway": "Prompting is not one clever sentence. It is arranging the evidence and boundaries the model can see."
      },
      {
        "id": "simon-context-engineering",
        "title": "Context engineering",
        "publisher": "Simon Willison",
        "published": "2025",
        "kind": "industry_blog",
        "url": "https://simonwillison.net/2025/Jun/27/context-engineering/",
        "signal": "Practitioners are naming context engineering as the craft of assembling the right prompt-time working set.",
        "readerTakeaway": "If the model ignores a fact, ask whether the fact was positioned, formatted, and prioritized like it mattered."
      },
      {
        "id": "anthropic-mcp",
        "title": "Introducing the Model Context Protocol",
        "publisher": "Anthropic",
        "published": "2024",
        "kind": "protocol",
        "url": "https://www.anthropic.com/news/model-context-protocol",
        "signal": "Model-to-tool interoperability is shifting from one-off connectors toward explicit protocols.",
        "readerTakeaway": "Before a model uses a tool, it should discover what the tool is, what schema it accepts, and what authority it has."
      },
      {
        "id": "google-a2a",
        "title": "A2A: A new era of agent interoperability",
        "publisher": "Google Developers Blog",
        "published": "2025",
        "kind": "protocol",
        "url": "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/",
        "signal": "Agent interoperability is becoming a platform concern, not only a prompt-design concern.",
        "readerTakeaway": "When two agents cooperate, the contract between them matters as much as either model."
      },
      {
        "id": "openai-agents-tools",
        "title": "New tools for building agents",
        "publisher": "OpenAI",
        "published": "2025",
        "kind": "official_docs",
        "url": "https://openai.com/index/new-tools-for-building-agents/",
        "signal": "Agent products are consolidating around model responses, tool calls, tracing, and managed action surfaces.",
        "readerTakeaway": "A serious agent demo should show the tool call, the trace or receipt, and the boundary, not only the final answer."
      },
      {
        "id": "openai-prompt-guide",
        "title": "Prompt engineering guide",
        "publisher": "OpenAI Platform",
        "published": "2026",
        "kind": "official_docs",
        "url": "https://platform.openai.com/docs/guides/prompt-engineering",
        "signal": "Official prompt guidance keeps converging on clear instructions, context, examples, and explicit output contracts.",
        "readerTakeaway": "The prompt that travels across models is the one that names the job, evidence, limits, and output shape."
      },
      {
        "id": "anthropic-prompt-guide",
        "title": "Prompt engineering overview",
        "publisher": "Anthropic Docs",
        "published": "2026",
        "kind": "official_docs",
        "url": "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview",
        "signal": "Provider-specific details differ, but task clarity, examples, role, and format remain stable cross-model levers.",
        "readerTakeaway": "Do not write a prompt for one brand personality. Write a contract a capable model can follow."
      },
      {
        "id": "gemini-prompt-guide",
        "title": "Gemini prompting strategies",
        "publisher": "Google AI for Developers",
        "published": "2026",
        "kind": "official_docs",
        "url": "https://ai.google.dev/gemini-api/docs/prompting-strategies",
        "signal": "Gemini guidance reinforces the same core pattern: clear task, sufficient context, examples, constraints, and testing.",
        "readerTakeaway": "Cross-model prompts work best when they are boringly explicit about success and failure."
      },
      {
        "id": "deepseek-r1",
        "title": "DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning",
        "publisher": "arXiv",
        "published": "2025",
        "kind": "paper",
        "url": "https://arxiv.org/abs/2501.12948",
        "signal": "Reasoning models made test-time search, verification, and longer deliberation mainstream product knobs.",
        "readerTakeaway": "The model may spend extra compute exploring possible paths. The user still needs evidence for the final path."
      },
      {
        "id": "humanitys-last-exam",
        "title": "Humanity's Last Exam",
        "publisher": "arXiv",
        "published": "2025",
        "kind": "paper",
        "url": "https://arxiv.org/abs/2501.14249",
        "signal": "Frontier evals are becoming stress tests for knowledge, reasoning, calibration, and overconfidence.",
        "readerTakeaway": "A hard benchmark is not a product guarantee. It is a map of where models still break."
      },
      {
        "id": "metr-long-tasks",
        "title": "Measuring AI ability to complete long tasks",
        "publisher": "METR / arXiv",
        "published": "2025",
        "kind": "paper",
        "url": "https://arxiv.org/abs/2503.14499",
        "signal": "Agent progress is increasingly measured by task horizon, recovery from errors, and sustained work over time.",
        "readerTakeaway": "The question is not only can the model answer. It is how long it can keep a goal alive without drifting."
      },
      {
        "id": "swe-bench-verified",
        "title": "Introducing SWE-bench Verified",
        "publisher": "OpenAI",
        "published": "2024",
        "kind": "paper",
        "url": "https://openai.com/index/introducing-swe-bench-verified/",
        "signal": "Coding-agent evaluation is moving toward reviewed, reproducible tasks with real repositories and tests.",
        "readerTakeaway": "A coding answer is not done when it sounds right. It is done when the repo evidence turns green."
      },
      {
        "id": "owasp-llm-top-10",
        "title": "OWASP Top 10 for Large Language Model Applications",
        "publisher": "OWASP",
        "published": "2025",
        "kind": "security_standard",
        "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
        "signal": "Prompt injection, insecure output handling, and excessive agency are now standard LLM application risks.",
        "readerTakeaway": "Security starts at the boundary between text, tools, data, and authority."
      },
      {
        "id": "openclaw-platform",
        "title": "OpenClaw-compatible PlatPhorm gateway",
        "publisher": "PlatPhormNews",
        "published": "2026",
        "kind": "platform_surface",
        "url": "https://claws.platphormnews.com",
        "signal": "OpenClaw is useful here as an integration lens: discover capabilities, draft toolchains, dry-run, validate, then protect execution.",
        "readerTakeaway": "The valuable demo is not pretending a tool ran. It is showing the chain that decides whether it should run."
      },
      {
        "id": "webhooklab-platform",
        "title": "WebhookLab public-safe contract testing",
        "publisher": "PlatPhormNews",
        "published": "2026",
        "kind": "platform_surface",
        "url": "https://webhooklab.platphormnews.com",
        "signal": "Webhook demos can teach signing, delivery, verification, retry, and replay without sending unsafe live events.",
        "readerTakeaway": "A webhook is an agreement plus a receipt. If you cannot verify the signature and event shape, do not trust the delivery."
      }
    ],
    "trends": [
      {
        "id": "mind-as-evidence-map",
        "title": "Seeing inside AI means evidence, not telepathy",
        "plainLanguage": "We do not get the model's private thoughts. We get clues: token probabilities, attention paths, features, circuits, traces, and tool receipts.",
        "advancedSignal": "Attribution graphs, activation patching, logit lenses, and sparse features are turning interpretability into causal hypothesis testing.",
        "aha": "The mind of AI is most visible when you compare what changed inside the model with what changed in the answer.",
        "demoMove": "Show one answer, highlight low-confidence tokens, draw a feature path, then ask which evidence is only a clue and which evidence is causal.",
        "operatorMove": "Treat every visualization as a hypothesis until an intervention or independent check changes the behavior.",
        "caution": "Do not equate a chain-of-thought transcript with the hidden computation that caused the answer.",
        "sourceIds": [
          "anthropic-circuit-tracing",
          "anthropic-attribution-graphs"
        ],
        "entryIds": [
          "mind-microscope",
          "circuit-tracing-is-partial",
          "activation-patching",
          "logit-lens"
        ],
        "sources": [
          {
            "id": "anthropic-circuit-tracing",
            "title": "Tracing the thoughts of a large language model",
            "publisher": "Anthropic",
            "published": "2025",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/news/tracing-thoughts-language-model",
            "signal": "Attribution graphs and circuit tracing are turning model internals into inspectable pathways rather than mystery boxes.",
            "readerTakeaway": "We cannot read private thoughts, but we can inspect partial evidence about which features and paths influenced an answer."
          },
          {
            "id": "anthropic-attribution-graphs",
            "title": "Attribution graph methods",
            "publisher": "Transformer Circuits / Anthropic",
            "published": "2025",
            "kind": "paper",
            "url": "https://transformer-circuits.pub/2025/attribution-graphs/methods.html",
            "signal": "Mechanistic interpretability is becoming a reproducible workflow: build graph, localize path, test causal contribution.",
            "readerTakeaway": "A beautiful graph is only a hypothesis until an intervention changes model behavior."
          }
        ]
      },
      {
        "id": "loops-over-one-shot",
        "title": "Loops beat one-shot answers for serious work",
        "plainLanguage": "A stronger AI workflow observes, decides, acts, checks, and revises. The check is where the magic becomes engineering.",
        "advancedSignal": "ReAct-style agent loops, evaluator-optimizer workflows, and long-task evals all point to sustained control loops rather than single completions.",
        "aha": "A loop is not repetition. It is a chance to compare the model's plan with the world before the next move.",
        "demoMove": "Run the same question as a one-shot answer and as a five-step loop with an explicit verifier after each step.",
        "operatorMove": "Design stop conditions, retry limits, and evidence checks before granting tools or longer task horizons.",
        "caution": "A loop without a verifier can amplify a mistake faster than a single answer.",
        "sourceIds": [
          "react-paper",
          "anthropic-effective-agents",
          "metr-long-tasks"
        ],
        "entryIds": [
          "agent-loops",
          "explain-inspect-repair-loop",
          "first-safe-agent-plan"
        ],
        "sources": [
          {
            "id": "react-paper",
            "title": "ReAct: Synergizing reasoning and acting in language models",
            "publisher": "arXiv",
            "published": "2022",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2210.03629",
            "signal": "The reason-act-observe rhythm remains the clearest first-pass model for agent loops.",
            "readerTakeaway": "An agent is not magic autonomy. It is a loop with observations, decisions, actions, and checks."
          },
          {
            "id": "anthropic-effective-agents",
            "title": "Building effective agents",
            "publisher": "Anthropic Engineering",
            "published": "2024",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/building-effective-agents",
            "signal": "Useful agents are usually simple workflows with clear tool boundaries before they are open-ended autonomy.",
            "readerTakeaway": "Start with a visible workflow, then let the model choose inside well-labeled rails."
          },
          {
            "id": "metr-long-tasks",
            "title": "Measuring AI ability to complete long tasks",
            "publisher": "METR / arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2503.14499",
            "signal": "Agent progress is increasingly measured by task horizon, recovery from errors, and sustained work over time.",
            "readerTakeaway": "The question is not only can the model answer. It is how long it can keep a goal alive without drifting."
          }
        ]
      },
      {
        "id": "context-is-product-surface",
        "title": "Context engineering is the new prompt engineering",
        "plainLanguage": "The prompt is more than the words you type. It is the whole working set the model sees: files, memories, tools, examples, and rules.",
        "advancedSignal": "Agent quality is increasingly constrained by context curation, source ordering, compression, and boundary placement.",
        "aha": "If the right fact is buried in the wrong place, the model can technically have it and still act like it never saw it.",
        "demoMove": "Place the same key fact at the beginning, middle, and end of a prompt, then compare which answers preserve it.",
        "operatorMove": "Build a source map before summary and put the highest-risk constraints near the edges of context.",
        "caution": "More context is not automatically better context.",
        "sourceIds": [
          "anthropic-context-engineering",
          "simon-context-engineering"
        ],
        "entryIds": [
          "context-is-the-prompt",
          "source-map-before-summary",
          "context-rot"
        ],
        "sources": [
          {
            "id": "anthropic-context-engineering",
            "title": "Effective context engineering for AI agents",
            "publisher": "Anthropic Engineering",
            "published": "2025",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents",
            "signal": "The practical prompt surface is the whole context stack: instructions, tools, memory, retrieved files, and stop rules.",
            "readerTakeaway": "Prompting is not one clever sentence. It is arranging the evidence and boundaries the model can see."
          },
          {
            "id": "simon-context-engineering",
            "title": "Context engineering",
            "publisher": "Simon Willison",
            "published": "2025",
            "kind": "industry_blog",
            "url": "https://simonwillison.net/2025/Jun/27/context-engineering/",
            "signal": "Practitioners are naming context engineering as the craft of assembling the right prompt-time working set.",
            "readerTakeaway": "If the model ignores a fact, ask whether the fact was positioned, formatted, and prioritized like it mattered."
          }
        ]
      },
      {
        "id": "protocols-before-agency",
        "title": "Agents need protocols before broad authority",
        "plainLanguage": "Before a model acts, it needs to know what tools exist, what schema they require, and what it is allowed to do.",
        "advancedSignal": "MCP, A2A, managed agent tools, and trace surfaces are converging on explicit contracts around tools and agent-to-agent work.",
        "aha": "Tool discovery is a safety feature because it turns invisible authority into inspectable capability.",
        "demoMove": "Show an unknown tool, inspect its schema, label public reads versus protected actions, then draft a dry run.",
        "operatorMove": "Require schema inspection and protected boundary checks before execution.",
        "caution": "Do not add generic tools just because an agent can call them. Tools must serve the site's real purpose.",
        "sourceIds": [
          "anthropic-mcp",
          "google-a2a",
          "openai-agents-tools"
        ],
        "entryIds": [
          "tool-protocols-over-adapters",
          "tool-dry-run",
          "public-private-sorting"
        ],
        "sources": [
          {
            "id": "anthropic-mcp",
            "title": "Introducing the Model Context Protocol",
            "publisher": "Anthropic",
            "published": "2024",
            "kind": "protocol",
            "url": "https://www.anthropic.com/news/model-context-protocol",
            "signal": "Model-to-tool interoperability is shifting from one-off connectors toward explicit protocols.",
            "readerTakeaway": "Before a model uses a tool, it should discover what the tool is, what schema it accepts, and what authority it has."
          },
          {
            "id": "google-a2a",
            "title": "A2A: A new era of agent interoperability",
            "publisher": "Google Developers Blog",
            "published": "2025",
            "kind": "protocol",
            "url": "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/",
            "signal": "Agent interoperability is becoming a platform concern, not only a prompt-design concern.",
            "readerTakeaway": "When two agents cooperate, the contract between them matters as much as either model."
          },
          {
            "id": "openai-agents-tools",
            "title": "New tools for building agents",
            "publisher": "OpenAI",
            "published": "2025",
            "kind": "official_docs",
            "url": "https://openai.com/index/new-tools-for-building-agents/",
            "signal": "Agent products are consolidating around model responses, tool calls, tracing, and managed action surfaces.",
            "readerTakeaway": "A serious agent demo should show the tool call, the trace or receipt, and the boundary, not only the final answer."
          }
        ]
      },
      {
        "id": "openclaw-as-visible-toolchain",
        "title": "OpenClaw is best taught as a visible toolchain",
        "plainLanguage": "OpenClaw is understandable when the chain is visible: discover, inspect, validate, dry-run, protect, then execute only when authorized.",
        "advancedSignal": "The PlatPhorm OpenClaw gateway should expose public-safe metadata and dry-run plans while keeping mutations behind PLATPHORM_API_KEY.",
        "aha": "The valuable question is not did the agent act. It is whether the chain proved the agent should be allowed to act.",
        "demoMove": "Animate an OpenClaw request moving through MCP/API discovery, schema validation, dry-run planning, and protected handoff.",
        "operatorMove": "Make dry-run evidence the artifact reviewed before any workflow or remediation action.",
        "caution": "Do not imply hosted OpenClaw runtime execution when the current surface is compatibility metadata and platform planning.",
        "sourceIds": [
          "openclaw-platform",
          "anthropic-mcp"
        ],
        "entryIds": [
          "openclaw-toolchain-dry-run",
          "first-safe-agent-plan",
          "integration-contract-cards"
        ],
        "sources": [
          {
            "id": "openclaw-platform",
            "title": "OpenClaw-compatible PlatPhorm gateway",
            "publisher": "PlatPhormNews",
            "published": "2026",
            "kind": "platform_surface",
            "url": "https://claws.platphormnews.com",
            "signal": "OpenClaw is useful here as an integration lens: discover capabilities, draft toolchains, dry-run, validate, then protect execution.",
            "readerTakeaway": "The valuable demo is not pretending a tool ran. It is showing the chain that decides whether it should run."
          },
          {
            "id": "anthropic-mcp",
            "title": "Introducing the Model Context Protocol",
            "publisher": "Anthropic",
            "published": "2024",
            "kind": "protocol",
            "url": "https://www.anthropic.com/news/model-context-protocol",
            "signal": "Model-to-tool interoperability is shifting from one-off connectors toward explicit protocols.",
            "readerTakeaway": "Before a model uses a tool, it should discover what the tool is, what schema it accepts, and what authority it has."
          }
        ]
      },
      {
        "id": "webhooks-as-receipts",
        "title": "Webhooks teach cause, delivery, and proof",
        "plainLanguage": "A webhook is a message from one system to another. The signature and event contract tell you whether to trust it.",
        "advancedSignal": "Webhook reliability depends on signing, idempotency, event schemas, delivery logs, retries, and replay boundaries.",
        "aha": "The event is not the proof. The verified signature, contract match, delivery receipt, and replay policy are the proof.",
        "demoMove": "Show event creation, signature generation, receiver verification, retry decision, and protected replay as separate states.",
        "operatorMove": "Use public-safe signature and contract checks for practice; require PLATPHORM_API_KEY for event creation, replay, or mutation.",
        "caution": "Never paste real secrets into public webhook demos or discovery files.",
        "sourceIds": [
          "webhooklab-platform",
          "owasp-llm-top-10"
        ],
        "entryIds": [
          "webhook-delivery-lifecycle",
          "receipts",
          "public-private-sorting"
        ],
        "sources": [
          {
            "id": "webhooklab-platform",
            "title": "WebhookLab public-safe contract testing",
            "publisher": "PlatPhormNews",
            "published": "2026",
            "kind": "platform_surface",
            "url": "https://webhooklab.platphormnews.com",
            "signal": "Webhook demos can teach signing, delivery, verification, retry, and replay without sending unsafe live events.",
            "readerTakeaway": "A webhook is an agreement plus a receipt. If you cannot verify the signature and event shape, do not trust the delivery."
          },
          {
            "id": "owasp-llm-top-10",
            "title": "OWASP Top 10 for Large Language Model Applications",
            "publisher": "OWASP",
            "published": "2025",
            "kind": "security_standard",
            "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
            "signal": "Prompt injection, insecure output handling, and excessive agency are now standard LLM application risks.",
            "readerTakeaway": "Security starts at the boundary between text, tools, data, and authority."
          }
        ]
      },
      {
        "id": "cross-model-prompt-contracts",
        "title": "Prompts that travel are contracts, not slogans",
        "plainLanguage": "OpenAI, Claude, and Gemini differ, but the best prompts give all of them the same useful structure: role, task, context, constraints, evidence, output shape, and stop rules.",
        "advancedSignal": "Official provider guidance keeps converging on explicit instructions, examples, structured outputs, testing, and clear context boundaries.",
        "aha": "A cross-model prompt works when the model can tell what counts as complete, partial, unknown, and unsafe.",
        "demoMove": "Run the same prompt skeleton against three model families, then compare which field fails first.",
        "operatorMove": "Version prompt contracts and test them against local fixtures instead of rewriting them for model brand voice.",
        "caution": "Provider-specific features still matter; the portable layer should not hide model-specific capabilities or limits.",
        "sourceIds": [
          "openai-prompt-guide",
          "anthropic-prompt-guide",
          "gemini-prompt-guide"
        ],
        "entryIds": [
          "cross-model-prompt-contract",
          "schema-first-output",
          "semantic-diff"
        ],
        "sources": [
          {
            "id": "openai-prompt-guide",
            "title": "Prompt engineering guide",
            "publisher": "OpenAI Platform",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://platform.openai.com/docs/guides/prompt-engineering",
            "signal": "Official prompt guidance keeps converging on clear instructions, context, examples, and explicit output contracts.",
            "readerTakeaway": "The prompt that travels across models is the one that names the job, evidence, limits, and output shape."
          },
          {
            "id": "anthropic-prompt-guide",
            "title": "Prompt engineering overview",
            "publisher": "Anthropic Docs",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview",
            "signal": "Provider-specific details differ, but task clarity, examples, role, and format remain stable cross-model levers.",
            "readerTakeaway": "Do not write a prompt for one brand personality. Write a contract a capable model can follow."
          },
          {
            "id": "gemini-prompt-guide",
            "title": "Gemini prompting strategies",
            "publisher": "Google AI for Developers",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://ai.google.dev/gemini-api/docs/prompting-strategies",
            "signal": "Gemini guidance reinforces the same core pattern: clear task, sufficient context, examples, constraints, and testing.",
            "readerTakeaway": "Cross-model prompts work best when they are boringly explicit about success and failure."
          }
        ]
      },
      {
        "id": "reasoning-models-need-receipts",
        "title": "Reasoning models make search visible, not automatically true",
        "plainLanguage": "Reasoning models can spend more time exploring. That is useful, but the final answer still needs receipts.",
        "advancedSignal": "Reinforcement learning for reasoning and test-time compute are changing how models allocate effort, especially on math, code, and multi-step tasks.",
        "aha": "A longer reasoning path is not proof. Proof is the artifact that survives checking.",
        "demoMove": "Compare a fast answer with a slower reasoned answer, then score both only by sources, tests, or calculations.",
        "operatorMove": "Escalate to reasoning models where uncertainty, task horizon, or decision impact justifies the extra latency.",
        "caution": "Do not reward verbose reasoning if the final artifact is unsupported.",
        "sourceIds": [
          "deepseek-r1",
          "swe-bench-verified"
        ],
        "entryIds": [
          "reasoning-as-search",
          "latency-budget",
          "receipts"
        ],
        "sources": [
          {
            "id": "deepseek-r1",
            "title": "DeepSeek-R1: Incentivizing reasoning capability in LLMs via reinforcement learning",
            "publisher": "arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2501.12948",
            "signal": "Reasoning models made test-time search, verification, and longer deliberation mainstream product knobs.",
            "readerTakeaway": "The model may spend extra compute exploring possible paths. The user still needs evidence for the final path."
          },
          {
            "id": "swe-bench-verified",
            "title": "Introducing SWE-bench Verified",
            "publisher": "OpenAI",
            "published": "2024",
            "kind": "paper",
            "url": "https://openai.com/index/introducing-swe-bench-verified/",
            "signal": "Coding-agent evaluation is moving toward reviewed, reproducible tasks with real repositories and tests.",
            "readerTakeaway": "A coding answer is not done when it sounds right. It is done when the repo evidence turns green."
          }
        ]
      },
      {
        "id": "evals-as-failure-maps",
        "title": "The new evals are failure maps",
        "plainLanguage": "Benchmarks are useful when they show where models still fail, not when they become scoreboard decoration.",
        "advancedSignal": "Humanity's Last Exam, SWE-bench Verified, and long-task evaluations push toward harder, more realistic failure discovery.",
        "aha": "A benchmark score is less useful than the broken examples it helps you test in your own product.",
        "demoMove": "Take one benchmark-style failure and turn it into a local fixture with an expected safe response.",
        "operatorMove": "Translate public benchmark failure patterns into small product-specific fixtures.",
        "caution": "Do not claim production safety from a general benchmark without local tests.",
        "sourceIds": [
          "humanitys-last-exam",
          "swe-bench-verified",
          "metr-long-tasks"
        ],
        "entryIds": [
          "benchmark-time-horizon",
          "eval-sandwich",
          "refusal-fixtures"
        ],
        "sources": [
          {
            "id": "humanitys-last-exam",
            "title": "Humanity's Last Exam",
            "publisher": "arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2501.14249",
            "signal": "Frontier evals are becoming stress tests for knowledge, reasoning, calibration, and overconfidence.",
            "readerTakeaway": "A hard benchmark is not a product guarantee. It is a map of where models still break."
          },
          {
            "id": "swe-bench-verified",
            "title": "Introducing SWE-bench Verified",
            "publisher": "OpenAI",
            "published": "2024",
            "kind": "paper",
            "url": "https://openai.com/index/introducing-swe-bench-verified/",
            "signal": "Coding-agent evaluation is moving toward reviewed, reproducible tasks with real repositories and tests.",
            "readerTakeaway": "A coding answer is not done when it sounds right. It is done when the repo evidence turns green."
          },
          {
            "id": "metr-long-tasks",
            "title": "Measuring AI ability to complete long tasks",
            "publisher": "METR / arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2503.14499",
            "signal": "Agent progress is increasingly measured by task horizon, recovery from errors, and sustained work over time.",
            "readerTakeaway": "The question is not only can the model answer. It is how long it can keep a goal alive without drifting."
          }
        ]
      },
      {
        "id": "security-is-tool-boundary",
        "title": "AI security lives at the text-tool boundary",
        "plainLanguage": "The risky moment is often when text becomes action: a prompt changes a tool call, a source injects instructions, or an output gets trusted too quickly.",
        "advancedSignal": "Prompt injection, excessive agency, insecure output handling, and data leakage are now baseline LLM app risks.",
        "aha": "The model is safest when it can read broadly, plan visibly, act narrowly, and stop cleanly.",
        "demoMove": "Show a harmless injected instruction inside retrieved text, then separate content from command.",
        "operatorMove": "Bind tools to trusted domains, schema validation, least authority, and protected action checks.",
        "caution": "Never let untrusted content become higher-priority instructions.",
        "sourceIds": [
          "owasp-llm-top-10",
          "openai-agents-tools"
        ],
        "entryIds": [
          "prompt-injection-is-a-tool-boundary",
          "red-team-mutants",
          "tool-dry-run"
        ],
        "sources": [
          {
            "id": "owasp-llm-top-10",
            "title": "OWASP Top 10 for Large Language Model Applications",
            "publisher": "OWASP",
            "published": "2025",
            "kind": "security_standard",
            "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
            "signal": "Prompt injection, insecure output handling, and excessive agency are now standard LLM application risks.",
            "readerTakeaway": "Security starts at the boundary between text, tools, data, and authority."
          },
          {
            "id": "openai-agents-tools",
            "title": "New tools for building agents",
            "publisher": "OpenAI",
            "published": "2025",
            "kind": "official_docs",
            "url": "https://openai.com/index/new-tools-for-building-agents/",
            "signal": "Agent products are consolidating around model responses, tool calls, tracing, and managed action surfaces.",
            "readerTakeaway": "A serious agent demo should show the tool call, the trace or receipt, and the boundary, not only the final answer."
          }
        ]
      }
    ],
    "demos": [
      {
        "id": "loops",
        "title": "Loops",
        "subtitle": "Observe, decide, act, check, reflect",
        "question": "What changes when AI stops answering once and starts checking itself against the world?",
        "firstPassMentalModel": "A loop is like solving a math problem, checking the work, and using the mistake to choose the next step.",
        "advancedMentalModel": "A loop is a bounded controller with state, observations, tool actions, verifier signals, stop rules, and retry budgets.",
        "steps": [
          {
            "label": "Observe",
            "action": "Read the question, sources, tool state, and current constraints.",
            "visibleSignal": "Source map, current state, missing evidence.",
            "safety": "Do not act while the world state is unknown."
          },
          {
            "label": "Decide",
            "action": "Choose one next move that can be verified.",
            "visibleSignal": "Plan line with target, reason, and stop condition.",
            "safety": "Prefer the smallest reversible move."
          },
          {
            "label": "Act",
            "action": "Run a read, draft, calculation, or protected tool only inside the boundary.",
            "visibleSignal": "Tool call preview or public-safe artifact.",
            "safety": "Mutations require PLATPHORM_API_KEY."
          },
          {
            "label": "Check",
            "action": "Compare the result with expected evidence.",
            "visibleSignal": "Pass, mismatch, missing receipt, or retry reason.",
            "safety": "A failed check stops the loop instead of polishing the error."
          },
          {
            "label": "Reflect",
            "action": "Update the next step, confidence, or refusal branch.",
            "visibleSignal": "Changed plan, not just longer prose.",
            "safety": "Reflection must change behavior or it is decoration."
          }
        ],
        "aha": "The check step is where AI becomes inspectable. Without it, the loop is just a confident answer repeated several times.",
        "tryThis": "Take one model answer and rewrite it as a five-step loop. Require a visible artifact after each step.",
        "publicSafeBoundary": "This demo explains loop mechanics and public-safe dry runs. It does not trigger external tools or protected actions.",
        "sourceIds": [
          "react-paper",
          "anthropic-effective-agents",
          "metr-long-tasks"
        ],
        "entryIds": [
          "agent-loops",
          "explain-inspect-repair-loop",
          "first-safe-agent-plan"
        ],
        "sources": [
          {
            "id": "react-paper",
            "title": "ReAct: Synergizing reasoning and acting in language models",
            "publisher": "arXiv",
            "published": "2022",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2210.03629",
            "signal": "The reason-act-observe rhythm remains the clearest first-pass model for agent loops.",
            "readerTakeaway": "An agent is not magic autonomy. It is a loop with observations, decisions, actions, and checks."
          },
          {
            "id": "anthropic-effective-agents",
            "title": "Building effective agents",
            "publisher": "Anthropic Engineering",
            "published": "2024",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/building-effective-agents",
            "signal": "Useful agents are usually simple workflows with clear tool boundaries before they are open-ended autonomy.",
            "readerTakeaway": "Start with a visible workflow, then let the model choose inside well-labeled rails."
          },
          {
            "id": "metr-long-tasks",
            "title": "Measuring AI ability to complete long tasks",
            "publisher": "METR / arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2503.14499",
            "signal": "Agent progress is increasingly measured by task horizon, recovery from errors, and sustained work over time.",
            "readerTakeaway": "The question is not only can the model answer. It is how long it can keep a goal alive without drifting."
          }
        ]
      },
      {
        "id": "openclaw",
        "title": "OpenClaw",
        "subtitle": "Capability discovery before agent authority",
        "question": "How do we show an agent workflow without pretending execution happened?",
        "firstPassMentalModel": "OpenClaw is the checklist a tool-using agent walks through before it is allowed to touch the real system.",
        "advancedMentalModel": "The PlatPhorm OpenClaw surface is an OpenClaw-compatible planning and validation gateway, not a claim that every hosted runtime mode is live.",
        "steps": [
          {
            "label": "Discover",
            "action": "Find the service purpose, MCP/API metadata, and public capabilities.",
            "visibleSignal": "Capability list and service boundary.",
            "safety": "Discovery is public read-only."
          },
          {
            "label": "Inspect",
            "action": "Read tool schemas, required inputs, and protected fields.",
            "visibleSignal": "Arguments, allowed values, and refusal states.",
            "safety": "Unknown schemas do not execute."
          },
          {
            "label": "Draft",
            "action": "Create a toolchain plan with target ids and expected output.",
            "visibleSignal": "Dry-run plan, not a success claim.",
            "safety": "No mutation occurs during planning."
          },
          {
            "label": "Validate",
            "action": "Check schema fit, trusted domain, and route compliance.",
            "visibleSignal": "Pass, degraded, or protected_required.",
            "safety": "A degraded check stays visible."
          },
          {
            "label": "Handoff",
            "action": "Prepare protected execution only when authorized.",
            "visibleSignal": "PLATPHORM_API_KEY boundary and verification artifact.",
            "safety": "The notebook does not run OpenClaw actions."
          }
        ],
        "aha": "OpenClaw is easiest to understand as a chain of evidence. Each step earns the right to ask for the next one.",
        "tryThis": "Pick one hypothetical remediation action and write the discovery, schema, dry-run, validation, and protected handoff fields.",
        "publicSafeBoundary": "This site only demonstrates the OpenClaw-compatible flow and links to the platform surface. Real execution belongs behind PLATPHORM_API_KEY on the owning service.",
        "sourceIds": [
          "openclaw-platform",
          "anthropic-mcp",
          "google-a2a"
        ],
        "entryIds": [
          "openclaw-toolchain-dry-run",
          "tool-protocols-over-adapters",
          "tool-dry-run"
        ],
        "sources": [
          {
            "id": "openclaw-platform",
            "title": "OpenClaw-compatible PlatPhorm gateway",
            "publisher": "PlatPhormNews",
            "published": "2026",
            "kind": "platform_surface",
            "url": "https://claws.platphormnews.com",
            "signal": "OpenClaw is useful here as an integration lens: discover capabilities, draft toolchains, dry-run, validate, then protect execution.",
            "readerTakeaway": "The valuable demo is not pretending a tool ran. It is showing the chain that decides whether it should run."
          },
          {
            "id": "anthropic-mcp",
            "title": "Introducing the Model Context Protocol",
            "publisher": "Anthropic",
            "published": "2024",
            "kind": "protocol",
            "url": "https://www.anthropic.com/news/model-context-protocol",
            "signal": "Model-to-tool interoperability is shifting from one-off connectors toward explicit protocols.",
            "readerTakeaway": "Before a model uses a tool, it should discover what the tool is, what schema it accepts, and what authority it has."
          },
          {
            "id": "google-a2a",
            "title": "A2A: A new era of agent interoperability",
            "publisher": "Google Developers Blog",
            "published": "2025",
            "kind": "protocol",
            "url": "https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/",
            "signal": "Agent interoperability is becoming a platform concern, not only a prompt-design concern.",
            "readerTakeaway": "When two agents cooperate, the contract between them matters as much as either model."
          }
        ]
      },
      {
        "id": "webhooks",
        "title": "Webhooks",
        "subtitle": "Event, signature, delivery, retry, replay",
        "question": "What proof should exist before a receiving system trusts an event?",
        "firstPassMentalModel": "A webhook is a doorbell from another app. The signature proves who rang it, and the event shape proves what they meant.",
        "advancedMentalModel": "A production webhook contract includes schema validation, signing, idempotency, delivery logs, retry policy, replay rules, and redacted artifacts.",
        "steps": [
          {
            "label": "Contract",
            "action": "Name event type, schema, source, and receiver expectations.",
            "visibleSignal": "Event contract and required fields.",
            "safety": "Unrecognized events do not mutate state."
          },
          {
            "label": "Sign",
            "action": "Generate or verify an HMAC-style signature with a secret kept out of public surfaces.",
            "visibleSignal": "Signature status, never raw secret.",
            "safety": "Do not paste real secrets into demos."
          },
          {
            "label": "Deliver",
            "action": "Send to receiver and record delivery metadata.",
            "visibleSignal": "Status code, timestamp, redacted headers.",
            "safety": "Live event creation is protected."
          },
          {
            "label": "Verify",
            "action": "Check signature, event id, timestamp tolerance, and schema.",
            "visibleSignal": "Accepted, rejected, duplicate, or stale.",
            "safety": "Verification failures are safe stop states."
          },
          {
            "label": "Replay",
            "action": "Retry or replay only through the owning protected service.",
            "visibleSignal": "Replay request id and reason.",
            "safety": "Replay requires PLATPHORM_API_KEY."
          }
        ],
        "aha": "The receiving system should trust the verified contract, not the model's summary of the event.",
        "tryThis": "Write a sample event contract, then list what would make the receiver reject it before any business logic runs.",
        "publicSafeBoundary": "This notebook demonstrates lifecycle thinking. Signature generation, event creation, replay, and delivery live on WebhookLab with its own public/protected boundary.",
        "sourceIds": [
          "webhooklab-platform",
          "owasp-llm-top-10"
        ],
        "entryIds": [
          "webhook-delivery-lifecycle",
          "receipts",
          "public-private-sorting"
        ],
        "sources": [
          {
            "id": "webhooklab-platform",
            "title": "WebhookLab public-safe contract testing",
            "publisher": "PlatPhormNews",
            "published": "2026",
            "kind": "platform_surface",
            "url": "https://webhooklab.platphormnews.com",
            "signal": "Webhook demos can teach signing, delivery, verification, retry, and replay without sending unsafe live events.",
            "readerTakeaway": "A webhook is an agreement plus a receipt. If you cannot verify the signature and event shape, do not trust the delivery."
          },
          {
            "id": "owasp-llm-top-10",
            "title": "OWASP Top 10 for Large Language Model Applications",
            "publisher": "OWASP",
            "published": "2025",
            "kind": "security_standard",
            "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
            "signal": "Prompt injection, insecure output handling, and excessive agency are now standard LLM application risks.",
            "readerTakeaway": "Security starts at the boundary between text, tools, data, and authority."
          }
        ]
      },
      {
        "id": "cross-model-prompts",
        "title": "Premier model prompts",
        "subtitle": "One contract, many model families",
        "question": "What kind of prompt survives OpenAI, Claude, Gemini, and future frontier models?",
        "firstPassMentalModel": "A good prompt is a worksheet: the model knows the job, the sources, the rules, the answer boxes, and when to say unknown.",
        "advancedMentalModel": "Portable prompts separate task contract from provider-specific affordances: role, objective, context ledger, constraints, output schema, uncertainty, and stop conditions.",
        "steps": [
          {
            "label": "Role",
            "action": "Name the useful role and the decision the answer supports.",
            "visibleSignal": "The model knows who the answer is for.",
            "safety": "Role never overrides policy or source evidence."
          },
          {
            "label": "Evidence",
            "action": "Provide allowed sources and what each can prove.",
            "visibleSignal": "Source ledger before final prose.",
            "safety": "Missing evidence becomes an allowed output."
          },
          {
            "label": "Constraints",
            "action": "State boundaries, exclusions, and protected actions.",
            "visibleSignal": "Clear public/protected/private split.",
            "safety": "Secrets and protected actions stay out of prompt output."
          },
          {
            "label": "Schema",
            "action": "Define fields, allowed states, and citation shape.",
            "visibleSignal": "The answer can be tested mechanically.",
            "safety": "Unknown and blocked are valid states."
          },
          {
            "label": "Review",
            "action": "Ask for counter-evidence, confidence reason, and next check.",
            "visibleSignal": "The answer exposes its weakest point.",
            "safety": "Confidence must be tied to evidence quality."
          }
        ],
        "aha": "The portable prompt is not the prettiest wording. It is the clearest contract for evidence, limits, and output shape.",
        "tryThis": "Paste the same contract prompt into two model families and compare which field fails first.",
        "publicSafeBoundary": "This demo provides prompt templates. It does not call external model APIs from the public page.",
        "sourceIds": [
          "openai-prompt-guide",
          "anthropic-prompt-guide",
          "gemini-prompt-guide"
        ],
        "entryIds": [
          "cross-model-prompt-contract",
          "schema-first-output",
          "semantic-diff"
        ],
        "sources": [
          {
            "id": "openai-prompt-guide",
            "title": "Prompt engineering guide",
            "publisher": "OpenAI Platform",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://platform.openai.com/docs/guides/prompt-engineering",
            "signal": "Official prompt guidance keeps converging on clear instructions, context, examples, and explicit output contracts.",
            "readerTakeaway": "The prompt that travels across models is the one that names the job, evidence, limits, and output shape."
          },
          {
            "id": "anthropic-prompt-guide",
            "title": "Prompt engineering overview",
            "publisher": "Anthropic Docs",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview",
            "signal": "Provider-specific details differ, but task clarity, examples, role, and format remain stable cross-model levers.",
            "readerTakeaway": "Do not write a prompt for one brand personality. Write a contract a capable model can follow."
          },
          {
            "id": "gemini-prompt-guide",
            "title": "Gemini prompting strategies",
            "publisher": "Google AI for Developers",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://ai.google.dev/gemini-api/docs/prompting-strategies",
            "signal": "Gemini guidance reinforces the same core pattern: clear task, sufficient context, examples, constraints, and testing.",
            "readerTakeaway": "Cross-model prompts work best when they are boringly explicit about success and failure."
          }
        ]
      },
      {
        "id": "ai-mind",
        "title": "AI mind microscope",
        "subtitle": "Signals, circuits, traces, receipts",
        "question": "What can we honestly see when we say we want to look inside the model?",
        "firstPassMentalModel": "Imagine a dark room with instruments. You cannot see everything, but each instrument shows one kind of signal.",
        "advancedMentalModel": "Interpretability combines output-side telemetry, internal activation evidence, causal interventions, and external tool traces.",
        "steps": [
          {
            "label": "Tokens",
            "action": "Inspect low-margin tokens and alternatives.",
            "visibleSignal": "Where the answer was fragile.",
            "safety": "Low confidence is not always wrong."
          },
          {
            "label": "Attention",
            "action": "Watch which tokens route information to which positions.",
            "visibleSignal": "Possible routing paths.",
            "safety": "Attention is evidence, not full explanation."
          },
          {
            "label": "Features",
            "action": "Probe or inspect sparse features associated with a concept.",
            "visibleSignal": "Concept directions and activation examples.",
            "safety": "Feature labels can overfit human interpretation."
          },
          {
            "label": "Circuits",
            "action": "Trace and patch components to test causal contribution.",
            "visibleSignal": "Behavior changes after intervention.",
            "safety": "Causal tests beat pretty diagrams."
          },
          {
            "label": "Receipts",
            "action": "Check external sources, tests, and tool traces.",
            "visibleSignal": "Evidence that survives outside the model.",
            "safety": "External proof outranks fluent self-report."
          }
        ],
        "aha": "Seeing inside AI means layering instruments. No single view is the mind; together they make behavior less mysterious.",
        "tryThis": "Take one answer and mark which parts could be checked by logprobs, attention, features, circuit tests, and external receipts.",
        "publicSafeBoundary": "This demo is explanatory. It does not expose private chain-of-thought, hidden provider internals, or live model traces.",
        "sourceIds": [
          "anthropic-circuit-tracing",
          "anthropic-attribution-graphs"
        ],
        "entryIds": [
          "mind-microscope",
          "circuit-tracing-is-partial",
          "logprobs"
        ],
        "sources": [
          {
            "id": "anthropic-circuit-tracing",
            "title": "Tracing the thoughts of a large language model",
            "publisher": "Anthropic",
            "published": "2025",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/news/tracing-thoughts-language-model",
            "signal": "Attribution graphs and circuit tracing are turning model internals into inspectable pathways rather than mystery boxes.",
            "readerTakeaway": "We cannot read private thoughts, but we can inspect partial evidence about which features and paths influenced an answer."
          },
          {
            "id": "anthropic-attribution-graphs",
            "title": "Attribution graph methods",
            "publisher": "Transformer Circuits / Anthropic",
            "published": "2025",
            "kind": "paper",
            "url": "https://transformer-circuits.pub/2025/attribution-graphs/methods.html",
            "signal": "Mechanistic interpretability is becoming a reproducible workflow: build graph, localize path, test causal contribution.",
            "readerTakeaway": "A beautiful graph is only a hypothesis until an intervention changes model behavior."
          }
        ]
      }
    ],
    "promptPatterns": [
      {
        "id": "evidence-first-answer",
        "title": "Evidence-first answer",
        "worksAcross": [
          "OpenAI GPT/reasoning models",
          "Anthropic Claude",
          "Google Gemini"
        ],
        "whenToUse": "Research, factual analysis, route audits, policy summaries, and any answer where source support matters.",
        "template": [
          "Task: Answer the question for [audience] using only the sources below.",
          "Source ledger: For each source, state what it can prove and what it cannot prove.",
          "Answer fields: answer, supporting receipts, counter-evidence, uncertainty, next check.",
          "If evidence is missing, return status: insufficient_evidence instead of guessing."
        ],
        "whyItWorks": "It makes source authority explicit before prose, which reduces the model's incentive to blend evidence with memory.",
        "failureMode": "The model may cite adjacent background unless you require claim-level receipts.",
        "sourceIds": [
          "openai-prompt-guide",
          "anthropic-prompt-guide",
          "gemini-prompt-guide"
        ],
        "entryIds": [
          "source-ledger-habit",
          "receipts",
          "counter-evidence"
        ],
        "sources": [
          {
            "id": "openai-prompt-guide",
            "title": "Prompt engineering guide",
            "publisher": "OpenAI Platform",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://platform.openai.com/docs/guides/prompt-engineering",
            "signal": "Official prompt guidance keeps converging on clear instructions, context, examples, and explicit output contracts.",
            "readerTakeaway": "The prompt that travels across models is the one that names the job, evidence, limits, and output shape."
          },
          {
            "id": "anthropic-prompt-guide",
            "title": "Prompt engineering overview",
            "publisher": "Anthropic Docs",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview",
            "signal": "Provider-specific details differ, but task clarity, examples, role, and format remain stable cross-model levers.",
            "readerTakeaway": "Do not write a prompt for one brand personality. Write a contract a capable model can follow."
          },
          {
            "id": "gemini-prompt-guide",
            "title": "Gemini prompting strategies",
            "publisher": "Google AI for Developers",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://ai.google.dev/gemini-api/docs/prompting-strategies",
            "signal": "Gemini guidance reinforces the same core pattern: clear task, sufficient context, examples, constraints, and testing.",
            "readerTakeaway": "Cross-model prompts work best when they are boringly explicit about success and failure."
          }
        ]
      },
      {
        "id": "tool-dry-run-contract",
        "title": "Tool dry-run contract",
        "worksAcross": [
          "OpenAI agents",
          "Claude tool use",
          "Gemini function calling"
        ],
        "whenToUse": "Any workflow that could mutate, send, replay, publish, delete, spend, or trigger another system.",
        "template": [
          "Before any tool call, produce a dry_run object.",
          "Include tool_name, target_ids, inputs, expected_effect, protected_boundary, stop_conditions, verification_plan.",
          "Do not execute if target_ids are broad, secrets are present, or protected auth is missing.",
          "Return protected_required when the action requires PLATPHORM_API_KEY."
        ],
        "whyItWorks": "It separates permission to plan from permission to execute, which is the core tool-safety boundary.",
        "failureMode": "A model may treat planning approval as execution approval unless the stop condition is explicit.",
        "sourceIds": [
          "openai-agents-tools",
          "anthropic-effective-agents",
          "owasp-llm-top-10"
        ],
        "entryIds": [
          "tool-dry-run",
          "public-private-sorting",
          "first-safe-agent-plan"
        ],
        "sources": [
          {
            "id": "openai-agents-tools",
            "title": "New tools for building agents",
            "publisher": "OpenAI",
            "published": "2025",
            "kind": "official_docs",
            "url": "https://openai.com/index/new-tools-for-building-agents/",
            "signal": "Agent products are consolidating around model responses, tool calls, tracing, and managed action surfaces.",
            "readerTakeaway": "A serious agent demo should show the tool call, the trace or receipt, and the boundary, not only the final answer."
          },
          {
            "id": "anthropic-effective-agents",
            "title": "Building effective agents",
            "publisher": "Anthropic Engineering",
            "published": "2024",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/building-effective-agents",
            "signal": "Useful agents are usually simple workflows with clear tool boundaries before they are open-ended autonomy.",
            "readerTakeaway": "Start with a visible workflow, then let the model choose inside well-labeled rails."
          },
          {
            "id": "owasp-llm-top-10",
            "title": "OWASP Top 10 for Large Language Model Applications",
            "publisher": "OWASP",
            "published": "2025",
            "kind": "security_standard",
            "url": "https://owasp.org/www-project-top-10-for-large-language-model-applications/",
            "signal": "Prompt injection, insecure output handling, and excessive agency are now standard LLM application risks.",
            "readerTakeaway": "Security starts at the boundary between text, tools, data, and authority."
          }
        ]
      },
      {
        "id": "cross-model-comparison",
        "title": "Cross-model comparison",
        "worksAcross": [
          "OpenAI",
          "Anthropic",
          "Google",
          "open-weight reasoning models"
        ],
        "whenToUse": "Prompt benching, model routing, field demos, and high-impact decisions where model disagreement is useful.",
        "template": [
          "Run the same task contract on each model without changing source material.",
          "Score outputs by fields: follows_schema, uses_receipts, names_uncertainty, avoids_overreach, helpful_next_action.",
          "Report disagreements before selecting a winner.",
          "Route by observed failure mode, not brand preference."
        ],
        "whyItWorks": "The same contract makes failures comparable and turns disagreement into a source of insight.",
        "failureMode": "Changing the prompt between models invalidates the comparison.",
        "sourceIds": [
          "humanitys-last-exam",
          "swe-bench-verified"
        ],
        "entryIds": [
          "model-routing",
          "cross-model-prompt-contract",
          "eval-sandwich"
        ],
        "sources": [
          {
            "id": "humanitys-last-exam",
            "title": "Humanity's Last Exam",
            "publisher": "arXiv",
            "published": "2025",
            "kind": "paper",
            "url": "https://arxiv.org/abs/2501.14249",
            "signal": "Frontier evals are becoming stress tests for knowledge, reasoning, calibration, and overconfidence.",
            "readerTakeaway": "A hard benchmark is not a product guarantee. It is a map of where models still break."
          },
          {
            "id": "swe-bench-verified",
            "title": "Introducing SWE-bench Verified",
            "publisher": "OpenAI",
            "published": "2024",
            "kind": "paper",
            "url": "https://openai.com/index/introducing-swe-bench-verified/",
            "signal": "Coding-agent evaluation is moving toward reviewed, reproducible tasks with real repositories and tests.",
            "readerTakeaway": "A coding answer is not done when it sounds right. It is done when the repo evidence turns green."
          }
        ]
      },
      {
        "id": "long-context-source-map",
        "title": "Long-context source map",
        "worksAcross": [
          "Long-context GPT models",
          "Claude",
          "Gemini"
        ],
        "whenToUse": "Large documents, repo audits, policy packs, discovery files, and multi-source research.",
        "template": [
          "First build a source map with source_id, owner, freshness, what_it_proves, limitations.",
          "Then answer using source_id references next to each material claim.",
          "Put critical constraints at the opening and repeat the highest-risk one at the end.",
          "Do not summarize sources that were not inspected."
        ],
        "whyItWorks": "It counters context rot by ranking evidence and making unsupported spans easy to spot.",
        "failureMode": "A giant context window can still bury decisive facts in the middle.",
        "sourceIds": [
          "anthropic-context-engineering",
          "simon-context-engineering"
        ],
        "entryIds": [
          "context-is-the-prompt",
          "context-rot",
          "source-map-before-summary"
        ],
        "sources": [
          {
            "id": "anthropic-context-engineering",
            "title": "Effective context engineering for AI agents",
            "publisher": "Anthropic Engineering",
            "published": "2025",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents",
            "signal": "The practical prompt surface is the whole context stack: instructions, tools, memory, retrieved files, and stop rules.",
            "readerTakeaway": "Prompting is not one clever sentence. It is arranging the evidence and boundaries the model can see."
          },
          {
            "id": "simon-context-engineering",
            "title": "Context engineering",
            "publisher": "Simon Willison",
            "published": "2025",
            "kind": "industry_blog",
            "url": "https://simonwillison.net/2025/Jun/27/context-engineering/",
            "signal": "Practitioners are naming context engineering as the craft of assembling the right prompt-time working set.",
            "readerTakeaway": "If the model ignores a fact, ask whether the fact was positioned, formatted, and prioritized like it mattered."
          }
        ]
      },
      {
        "id": "aha-check",
        "title": "AHA check",
        "worksAcross": [
          "ChatGPT",
          "Claude",
          "Gemini",
          "local assistants"
        ],
        "whenToUse": "Framing concepts that need to ramp from first exposure to operator-level judgment.",
        "template": [
          "Explain the concept in plain language in three sentences.",
          "Show the concrete artifact the reader should inspect.",
          "Name one safe mistake and the repair habit.",
          "End with: Before I thought ___. Now I inspect ___. Next I will ___."
        ],
        "whyItWorks": "It forces the model to teach mechanism, artifact, failure, and transfer instead of producing a polished mini-essay.",
        "failureMode": "The explanation may stay inspirational unless the inspected artifact is specific.",
        "sourceIds": [
          "anthropic-effective-agents",
          "openai-prompt-guide"
        ],
        "entryIds": [
          "plain-then-precise",
          "aha-from-mistake",
          "aha-checkpoints"
        ],
        "sources": [
          {
            "id": "anthropic-effective-agents",
            "title": "Building effective agents",
            "publisher": "Anthropic Engineering",
            "published": "2024",
            "kind": "lab_blog",
            "url": "https://www.anthropic.com/engineering/building-effective-agents",
            "signal": "Useful agents are usually simple workflows with clear tool boundaries before they are open-ended autonomy.",
            "readerTakeaway": "Start with a visible workflow, then let the model choose inside well-labeled rails."
          },
          {
            "id": "openai-prompt-guide",
            "title": "Prompt engineering guide",
            "publisher": "OpenAI Platform",
            "published": "2026",
            "kind": "official_docs",
            "url": "https://platform.openai.com/docs/guides/prompt-engineering",
            "signal": "Official prompt guidance keeps converging on clear instructions, context, examples, and explicit output contracts.",
            "readerTakeaway": "The prompt that travels across models is the one that names the job, evidence, limits, and output shape."
          }
        ]
      }
    ],
    "frontendRoadmap": [
      {
        "id": "mind-microscope",
        "title": "Mind microscope lane",
        "userMoment": "The reader sees one AI answer split into tokens, attention clues, feature hypotheses, circuit tests, and external receipts.",
        "interaction": "Animated instrument rail with hover states for what each signal can and cannot prove.",
        "evidence": "Backed by circuit tracing, attribution graphs, and existing notebook entries on logprobs, attention, patching, and receipts.",
        "status": "ready"
      },
      {
        "id": "loop-simulator",
        "title": "Loop simulator",
        "userMoment": "The class watches an agent plan change after a failed check instead of reading a final polished answer.",
        "interaction": "Five-step animated loop with pass, retry, protected_required, and stop states.",
        "evidence": "Grounded in ReAct, effective agent workflows, and the site's dry-run / protected-boundary content.",
        "status": "ready"
      },
      {
        "id": "openclaw-chain",
        "title": "OpenClaw chain viewer",
        "userMoment": "The reader understands OpenClaw as discover, inspect, validate, dry-run, and protected handoff.",
        "interaction": "Toolchain path cards with schema and boundary callouts.",
        "evidence": "Uses public-safe OpenClaw-compatible platform surface descriptions without claiming hosted runtime execution.",
        "status": "ready"
      },
      {
        "id": "webhook-receipt-lab",
        "title": "Webhook receipt lab",
        "userMoment": "The reader can explain why an unsigned or malformed event must be rejected before business logic.",
        "interaction": "Contract-sign-deliver-verify-replay lane with secret-redaction and protected replay badges.",
        "evidence": "Grounded in WebhookLab public/protected boundaries and OWASP LLM app security risks.",
        "status": "ready"
      },
      {
        "id": "prompt-bench",
        "title": "Cross-model prompt bench",
        "userMoment": "The reader runs one prompt contract mentally across premier models and sees which field fails first.",
        "interaction": "Prompt pattern cards with structured templates, failure modes, and fixture ideas.",
        "evidence": "Backed by official OpenAI, Anthropic, and Gemini prompt guidance.",
        "status": "next"
      },
      {
        "id": "research-ledger",
        "title": "Research source ledger",
        "userMoment": "A reader can open the source behind every trend and see which claim that source supports.",
        "interaction": "Filterable source grid by paper, protocol, docs, security standard, and PlatPhorm surface.",
        "evidence": "No hidden trend claims; source ids are exposed in /api/v1/research-trends and llms-index.json.",
        "status": "ready"
      }
    ]
  },
  "operatorPatterns": {
    "service": "ai-insights-for-humans",
    "generatedAt": "2026-07-21T08:35:50.366Z",
    "purpose": "Public-safe operator-pattern writeup derived from observable PlatPhormNews workflow behavior: what to copy, what to watch, and how to repair the rough edges.",
    "evidenceBoundary": "This is not a private personality profile. It is a workflow analysis based on observed product instructions, repository constraints, and platform operating patterns.",
    "strengths": [
      {
        "id": "raise-the-bar-after-green",
        "type": "strength",
        "title": "Raise the bar after the first green check",
        "plainLanguage": "A first working version is treated as the start of the real pass, not the finish line.",
        "whatItLooksLike": "After build or deploy succeeds, the next request pushes into content depth, routes, discovery, tests, mobile behavior, and live surfaces.",
        "whyItWorks": "Most weak AI products fail in the gap between local success and operator-grade usefulness. This habit keeps pressure on the gap.",
        "failureMode": "The finish line can move faster than the team can name what done means.",
        "repairMove": "Convert the next push into a named acceptance target: content, route, test, live smoke, or cross-site handoff.",
        "practiceMove": "Take a green build and list the evidence still missing before calling the product ready.",
        "relatedEntryIds": [
          "eval-sandwich",
          "source-ledger-habit",
          "benchmark-time-horizon"
        ]
      },
      {
        "id": "no-fake-success",
        "type": "strength",
        "title": "Reject fake success aggressively",
        "plainLanguage": "If a system did not send, run, publish, replay, or verify something, the UI should not pretend it did.",
        "whatItLooksLike": "Buttons, reports, demo tracks, MCP tools, and status cards need to say public-safe, protected_required, degraded, unsupported, or ready with real evidence.",
        "whyItWorks": "AI systems get dangerous when fluent summaries hide missing execution. Honest state labels preserve trust.",
        "failureMode": "The product can feel less magical because it refuses to fake the last mile.",
        "repairMove": "Make the boundary useful: show the dry run, the missing auth, the required receipt, and the next real action.",
        "practiceMove": "Take five shiny UI claims and label each one real, simulated, protected, degraded, or fake.",
        "relatedEntryIds": [
          "trust-but-verify-buttons",
          "tool-dry-run",
          "webhook-delivery-lifecycle"
        ]
      },
      {
        "id": "platform-contract-instinct",
        "type": "strength",
        "title": "Think in platform contracts",
        "plainLanguage": "Every site still does its own job, but it also needs standard discovery, health, auth, docs, feeds, and machine-readable surfaces.",
        "whatItLooksLike": "A feature request quickly turns into questions about OpenAPI, llms files, MCP, RSS, sitemap, trust policy, route compliance, and tests.",
        "whyItWorks": "Humans get the usable page. Agents get the contract. Operators get a way to verify both.",
        "failureMode": "The shared platform layer can crowd out the site's unique product if the purpose is not named first.",
        "repairMove": "Start each pass with the site role, then add only the platform surfaces that make that role more usable or inspectable.",
        "practiceMove": "Pick a small app and write its unique purpose before listing the standard platform routes it should expose.",
        "relatedEntryIds": [
          "tool-protocols-over-adapters",
          "public-private-sorting",
          "integration-contract-cards"
        ]
      },
      {
        "id": "network-first-thinking",
        "type": "strength",
        "title": "Think in networks, not isolated pages",
        "plainLanguage": "A useful AI learning surface should connect to definitions, notes, workflows, traces, evals, webhooks, and source ledgers where they actually help.",
        "whatItLooksLike": "The same concept gets linked to Dictionary, Notes, MCP, WebhookLab, OpenClaw, BrowserOps, Evals, and public JSON when those handoffs are real.",
        "whyItWorks": "AI work is rarely a single-page event. Learning, evidence, action, and verification usually live in different systems.",
        "failureMode": "Too many integrations can become decorative navigation instead of real workflow support.",
        "repairMove": "Every integration card must name owner, public reads, protected actions, and what this page does not do.",
        "practiceMove": "Map one AI investigation across term definition, note capture, tool dry run, route check, and evidence report.",
        "relatedEntryIds": [
          "dictionary-backed-verification",
          "notes-as-observation-log",
          "integration-contract-cards"
        ]
      },
      {
        "id": "plain-to-operator-ramp",
        "type": "strength",
        "title": "Build the ramp from plain reading to operator judgment",
        "plainLanguage": "The content should start in plain language and still scale toward advanced AI system judgment.",
        "whatItLooksLike": "A walkthrough starts with plain terms, then adds artifacts, receipts, schemas, boundary checks, evals, and cross-site workflows.",
        "whyItWorks": "Simple language lowers first-contact friction. Operator language gives the reader somewhere real to climb.",
        "failureMode": "If too much advanced machinery appears at once, the mechanism disappears behind vocabulary.",
        "repairMove": "Use a ladder: word, example, failure, workflow, protected boundary, verification.",
        "practiceMove": "Rewrite one advanced AI concept as a hallway explanation, then as an operator checklist.",
        "relatedEntryIds": [
          "plain-then-precise",
          "concept-ladder",
          "readiness-red-yellow-green"
        ]
      },
      {
        "id": "blunt-artifact-pressure",
        "type": "strength",
        "title": "Use blunt language to force artifact clarity",
        "plainLanguage": "Vague product language gets cut quickly when it does not point to a real action, route, source, or receipt.",
        "whatItLooksLike": "Phrases that sound strategic but do not help the user are removed or replaced with concrete content and working buttons.",
        "whyItWorks": "AI products are already full of vague confidence. Direct language pushes the work back to evidence.",
        "failureMode": "The urgency can sound like impatience when the missing artifact has not been named yet.",
        "repairMove": "Translate frustration into a defect sentence: this label implies X, but the product only does Y.",
        "practiceMove": "Take a vague AI dashboard sentence and rewrite it as a testable product promise.",
        "relatedEntryIds": [
          "artifact-questions",
          "trust-but-verify-buttons",
          "source-map-before-summary"
        ]
      }
    ],
    "dragPatterns": [
      {
        "id": "scope-pressure-without-priority",
        "type": "drag",
        "title": "Scope pressure can outrun priority",
        "plainLanguage": "More content, more polish, more integrations, and more tests are often right. But without ordering, everything becomes urgent.",
        "whatItLooksLike": "Requests stack dramatic content, live research, cross-site integrations, e2e tests, focus mode, and polish into one moving target.",
        "whyItWorks": "The ambition catches shallow work. It prevents a small green slice from masquerading as product quality.",
        "failureMode": "The next best action gets blurry, and useful work risks turning into broad motion.",
        "repairMove": "Force a three-lane board: must ship now, should expose publicly, and should queue as next content.",
        "practiceMove": "Sort ten improvement ideas into now, next, and later based on user impact and evidence risk.",
        "relatedEntryIds": [
          "source-ledger-habit",
          "eval-sandwich",
          "misconception-map"
        ]
      },
      {
        "id": "deployed-before-fresh-local-proof",
        "type": "drag",
        "title": "Deploy cadence can get ahead of local proof",
        "plainLanguage": "Fast deploys are useful, but the team must still separate local source, preview, production, and live alias evidence.",
        "whatItLooksLike": "A deployed update may become the new baseline while the next request assumes every current change is already live.",
        "whyItWorks": "Fast iteration keeps momentum and gets real surfaces in front of users.",
        "failureMode": "People can talk about live behavior, local behavior, and intended behavior as if they are the same thing.",
        "repairMove": "State the evidence level in every report: local fixed, tests green, build green, preview deployed, production verified.",
        "practiceMove": "Label five claims by evidence level before deciding whether a feature is truly done.",
        "relatedEntryIds": [
          "receipts",
          "source-map-before-summary",
          "memory-hygiene"
        ]
      },
      {
        "id": "content-volume-can-crowd-the-signal",
        "type": "drag",
        "title": "Content volume can crowd the signal",
        "plainLanguage": "A lot of good content can still become hard to scan if the page does not guide attention.",
        "whatItLooksLike": "Research trends, tips, demos, source ledgers, platform tips, entries, and integrations all compete for first-read attention.",
        "whyItWorks": "Depth is the product's advantage; shallow content would underserve serious readers.",
        "failureMode": "The reader treats everything as equally important and misses the one AHA moment they needed.",
        "repairMove": "Make every dense section answer: start here, inspect this, try this, stop here.",
        "practiceMove": "Take a dense section and mark the single first action a new reader should take.",
        "relatedEntryIds": [
          "aha-checkpoints",
          "self-quiz-cards",
          "focus-fullscreen-mode"
        ]
      },
      {
        "id": "platform-standard-can-flatten-identity",
        "type": "drag",
        "title": "The platform standard can flatten product identity",
        "plainLanguage": "A strong shared contract is good, but not every site should feel like the same observability dashboard.",
        "whatItLooksLike": "Route compliance, MCP, trust policy, trace context, and discovery can become louder than the actual product job.",
        "whyItWorks": "Standard surfaces make the network agent-operable and testable.",
        "failureMode": "An insight notebook, game, docs site, and webhook lab can start sounding like the same control panel.",
        "repairMove": "Put the product purpose at the top of every pass, then wrap the standard around that purpose.",
        "practiceMove": "Compare two sites and write one sentence that must stay different before listing the shared routes.",
        "relatedEntryIds": [
          "integration-contract-cards",
          "tool-protocols-over-adapters",
          "public-private-sorting"
        ]
      },
      {
        "id": "implicit-context-burden",
        "type": "drag",
        "title": "Implicit context can become a hidden burden",
        "plainLanguage": "When the operator says continue, they often know the whole context. The agent may need to reconstruct it from repo state, memory, live behavior, and prior instructions.",
        "whatItLooksLike": "A short follow-up can carry a lot of implied scope: latest deployment state, product tone, platform contract, and unresolved gaps.",
        "whyItWorks": "Short commands preserve momentum and avoid restating what should already be known.",
        "failureMode": "If the agent reconstructs the wrong context, it can optimize an older goal or miss the current priority.",
        "repairMove": "Add one line when redirecting: current target, unacceptable failure, and what must be true when done.",
        "practiceMove": "Turn a vague continue request into a one-sentence acceptance target without losing urgency.",
        "relatedEntryIds": [
          "memory-hygiene",
          "source-map-before-summary",
          "artifact-questions"
        ]
      },
      {
        "id": "more-can-outrun-source-quality",
        "type": "drag",
        "title": "More can outrun source quality",
        "plainLanguage": "More research, tips, and insights are valuable only when each claim has a job and a source boundary.",
        "whatItLooksLike": "The request for more content can tempt the system to summarize too broadly or treat trend noise as durable truth.",
        "whyItWorks": "A broad radar catches emerging patterns before they become obvious.",
        "failureMode": "Quantity can make weak sources look strong because the page feels substantial.",
        "repairMove": "Use a source ledger: source, what it proves, what it cannot prove, and what should be rechecked later.",
        "practiceMove": "Take three sources and state what each one can prove before writing any trend summary.",
        "relatedEntryIds": [
          "source-ledger-habit",
          "citation-triangulation",
          "definition-vs-proof"
        ]
      }
    ],
    "repairLoop": [
      {
        "label": "Name the job",
        "move": "Start with the site's actual product purpose before adding platform surfaces.",
        "evidence": "A one-sentence role that would still make sense to a first-time user.",
        "watchout": "Skipping straight to routes, dashboards, or MCP because those are familiar."
      },
      {
        "label": "Expose the contract",
        "move": "List public reads, protected actions, discovery files, and no-fake-data boundaries.",
        "evidence": "OpenAPI, llms, trust policy, route inventory, and UI labels agree.",
        "watchout": "A button or card implies an action that the code does not perform."
      },
      {
        "label": "Write the dense field note",
        "move": "Add real explanations, AHA moments, watchouts, and exercises that ramp from first contact to operator judgment.",
        "evidence": "A reader can say what changed in how they inspect the system.",
        "watchout": "More words without a clearer next action."
      },
      {
        "label": "Prove the surface",
        "move": "Run typecheck, lint, unit tests, build, and browser checks across desktop and mobile.",
        "evidence": "Commands run and failures either fixed or stated plainly.",
        "watchout": "Treating build green as proof that the product is usable."
      },
      {
        "label": "Mark the remaining gap",
        "move": "Separate local fixed, preview deployed, production verified, and next remediation.",
        "evidence": "The final report says what changed and what remains.",
        "watchout": "Letting momentum blur what is actually live."
      }
    ],
    "prompts": [
      {
        "id": "copy-the-good",
        "title": "Copy the good operator move",
        "useWhen": "You want a reader or agent to imitate the strongest parts of this working style.",
        "prompt": [
          "Study this workflow and extract the operator moves worth copying.",
          "For each move, return: name, visible behavior, why it works, evidence required, and one practice move.",
          "Do not praise vibes. Only include moves that change product quality or verification quality."
        ],
        "outputContract": [
          "strengths: array of named patterns",
          "evidence: artifact or behavior supporting each pattern",
          "practice: one transfer exercise per pattern"
        ]
      },
      {
        "id": "name-the-drag",
        "title": "Name the drag without softening it",
        "useWhen": "You need a candid review of where an ambitious operator style creates risk.",
        "prompt": [
          "Study this workflow and name the drag patterns.",
          "For each drag pattern, return: what triggers it, why it is understandable, how it breaks work, and the smallest repair move.",
          "Be direct, but do not psychologize. Keep it about observable workflow behavior."
        ],
        "outputContract": [
          "dragPatterns: array of observable risks",
          "repairMove: concrete action the operator or agent can take next",
          "boundary: what not to infer from the evidence"
        ]
      },
      {
        "id": "turn-continue-into-proof",
        "title": "Turn continue into proof",
        "useWhen": "The instruction is short, urgent, and packed with implied context.",
        "prompt": [
          "The user said continue. Reconstruct the current goal from repo state, prior instructions, and live surface evidence.",
          "Return the next three proof-producing actions, the files/routes affected, and the command chain that will prove completion.",
          "If assumptions are necessary, state them before acting."
        ],
        "outputContract": [
          "goal: current target in one sentence",
          "proofActions: exactly three actions",
          "verification: commands or live checks",
          "risk: what could be stale or ambiguous"
        ]
      }
    ]
  },
  "routes": [
    {
      "method": "GET",
      "path": "/",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Public AI insights notebook and reading paths."
    },
    {
      "method": "GET",
      "path": "/api/health",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Platform health payload for the publication."
    },
    {
      "method": "GET",
      "path": "/api/v1/health",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Versioned platform health payload."
    },
    {
      "method": "GET",
      "path": "/api/docs",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Machine-readable API and route documentation."
    },
    {
      "method": "GET",
      "path": "/api/v1/entries",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only JSON index of notebook entries."
    },
    {
      "method": "GET",
      "path": "/api/v1/entries/{id}",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only JSON detail for one notebook entry."
    },
    {
      "method": "GET",
      "path": "/api/v1/focus-mode",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only focus frames and practice loop payload."
    },
    {
      "method": "GET",
      "path": "/api/v1/integrations",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only Dictionary and Notes integration map with public handoff boundaries."
    },
    {
      "method": "GET",
      "path": "/api/v1/platform-literacy",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only interactive tips distilled from PlatPhormNews root discovery and policy surfaces."
    },
    {
      "method": "GET",
      "path": "/api/v1/research-trends",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only source-backed AI research trends, public-safe demonstrations, and cross-model prompt contracts."
    },
    {
      "method": "GET",
      "path": "/api/v1/operator-patterns",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Read-only operator strengths, drag patterns, repair loops, and reusable workflow prompts."
    },
    {
      "method": "POST",
      "path": "/api/v1/reports",
      "status": "implemented",
      "public": false,
      "protected": true,
      "description": "Protected generation of a real notebook/platform summary report."
    },
    {
      "method": "GET",
      "path": "/api/mcp",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "MCP metadata and JSON-RPC usage information."
    },
    {
      "method": "POST",
      "path": "/api/mcp",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "JSON-RPC 2.0 MCP endpoint for real notebook tools, resources, and prompts."
    },
    {
      "method": "GET",
      "path": "/openapi.yaml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "OpenAPI 3.1 contract for public and protected routes."
    },
    {
      "method": "GET",
      "path": "/llms.txt",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Concise LLM-readable site summary."
    },
    {
      "method": "GET",
      "path": "/llms-full.txt",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Complete LLM-readable notebook and platform summary."
    },
    {
      "method": "GET",
      "path": "/llms-index.json",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Structured LLM index generated from real entries."
    },
    {
      "method": "GET",
      "path": "/robots.txt",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Crawler policy and sitemap pointer."
    },
    {
      "method": "GET",
      "path": "/sitemap.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Canonical URL sitemap for the notebook."
    },
    {
      "method": "GET",
      "path": "/sitemap-index.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Sitemap index for platform crawlers."
    },
    {
      "method": "GET",
      "path": "/sitemap-full.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Complete sitemap covering product and machine-readable routes."
    },
    {
      "method": "GET",
      "path": "/humans.txt",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Human-readable ownership, purpose, attribution, and contact details."
    },
    {
      "method": "GET",
      "path": "/rss.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "RSS feed generated from notebook entries."
    },
    {
      "method": "GET",
      "path": "/feed.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "RSS-compatible feed alias."
    },
    {
      "method": "GET",
      "path": "/atom.xml",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Atom feed generated from notebook entries."
    },
    {
      "method": "GET",
      "path": "/manifest.webmanifest",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Web app manifest for install and preview surfaces."
    },
    {
      "method": "GET",
      "path": "/.well-known/mcp.json",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "MCP capability discovery manifest."
    },
    {
      "method": "GET",
      "path": "/.well-known/agents.json",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Agent-facing route and policy discovery manifest."
    },
    {
      "method": "GET",
      "path": "/.well-known/security.txt",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Security contact and policy file."
    },
    {
      "method": "GET",
      "path": "/.well-known/trust.json",
      "status": "implemented",
      "public": true,
      "protected": false,
      "description": "Trust, auth, public/protected, and exposure policy."
    }
  ],
  "routeCompliance": {
    "requiredRoutes": 22,
    "implementedRequiredRoutes": 22,
    "missingRequiredRoutes": [],
    "score": 1
  },
  "entries": [
    {
      "id": "mind-microscope",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use a mind microscope, not mind reading",
      "body": "You cannot open an AI model and read a private thought. You can inspect signals: tokens, attention, features, circuits, traces, tests, and receipts. The skill is knowing what each signal can prove and where it can fool you.",
      "tag": "interpretability",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": "A signal is a clue. A causal intervention is stronger evidence.",
      "insight": {
        "aha": "Seeing inside AI means layering instruments, not pretending one transcript reveals the whole hidden computation.",
        "tryThis": "Take one model answer and label which parts you could inspect with logprobs, attention, feature probes, circuit tests, and external receipts.",
        "watchFor": [
          "Treating chain-of-thought as the literal hidden cause",
          "One visualization presented as the whole explanation",
          "Internal signals trusted more than external proof"
        ],
        "labId": "logprobs"
      },
      "extended": [
        "The phrase seeing inside AI is useful only if we keep it honest. We are not watching a human-like inner monologue. We are reading instruments that expose partial evidence about how an answer formed.",
        "Token probabilities show fragile words. Attention can show routing clues. Probes can show where a concept is readable. Sparse features can separate tangled activation directions. Activation patching and circuit tracing can test whether a component actually changes behavior.",
        "The AHA for readers is that no single view is the mind. The strongest review layers several instruments and then asks what changed in the output when the internal signal changed."
      ],
      "url": "https://tips.platphormnews.com/entries/mind-microscope"
    },
    {
      "id": "circuit-tracing-is-partial",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Circuit tracing gives hypotheses before certainty",
      "body": "A circuit diagram can make a model feel legible, but the diagram is not the final answer. Treat each path as a hypothesis: this feature may have helped cause this behavior. Then test it with interventions or outside evidence.",
      "tag": "interpretability",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A circuit trace becomes persuasive when changing the suspected component changes the behavior you care about.",
        "tryThis": "Write one circuit-tracing claim as a hypothesis, then name the intervention or output check that would test it.",
        "watchFor": [
          "Beautiful attribution paths with no behavioral intervention",
          "Feature labels that sound more precise than the evidence",
          "Ignoring alternative circuits that could explain the same output"
        ],
        "labId": "activation-patching"
      },
      "extended": [
        "Modern interpretability is moving from screenshots of attention to causal stories about features and pathways. That is progress, but it also creates a new trap: the story can look more complete than the evidence.",
        "A good field demo should label each layer: observed output, suspected feature, traced path, causal test, and external receipt. Readers should be able to say which part is a clue and which part actually changed the model's behavior.",
        "This habit prevents interpretability theater. The beautiful graph earns trust only when it survives a behavioral check."
      ],
      "url": "https://tips.platphormnews.com/entries/circuit-tracing-is-partial"
    },
    {
      "id": "agent-loops",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Frame agents as loops with checks",
      "body": "An agent is easier to understand as a loop: observe, decide, act, check, reflect. The check is the important part. It turns a confident guess into a workflow that can notice when the world disagrees.",
      "tag": "agents",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "The check step is what separates an agent loop from a repeated confident guess.",
        "tryThis": "Rewrite one one-shot AI answer as observe, decide, act, check, reflect, and require a visible artifact for every step.",
        "watchFor": [
          "Loops with no stop condition",
          "Reflection that never changes the next action",
          "Retry logic that repeats the same failing move"
        ]
      },
      "extended": [
        "People often hear agent and imagine a little worker with judgment. A clearer frame is a controller. It reads state, chooses one next step, takes an allowed action, checks the result, then decides whether to continue or stop.",
        "The loop must have boundaries: what the agent may read, which tools it may call, when it must ask for PLATPHORM_API_KEY, and which check ends the run. Without those boundaries, a loop can amplify the first wrong assumption.",
        "The AHA is that autonomy is not the absence of control. Good autonomy is visible control repeated safely."
      ],
      "url": "https://tips.platphormnews.com/entries/agent-loops"
    },
    {
      "id": "openclaw-toolchain-dry-run",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "OpenClaw is a toolchain you can inspect",
      "body": "Frame OpenClaw as a chain: discover the service, inspect the MCP or API contract, validate the schema, draft the toolchain, dry-run the plan, and only then prepare protected execution.",
      "tag": "agents",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": "The learning value is in the visible chain, not in pretending a protected action already ran.",
      "insight": {
        "aha": "OpenClaw readiness is a chain of evidence: capability, schema, dry run, boundary, verifier, and receipt.",
        "tryThis": "Draft an OpenClaw-style dry run for one remediation action and mark every public read versus protected action.",
        "watchFor": [
          "Planning language that implies execution already happened",
          "Missing target ids or schema validation",
          "Protected actions shown without PLATPHORM_API_KEY boundary"
        ]
      },
      "extended": [
        "For this notebook, OpenClaw should be presented as an OpenClaw-compatible planning and validation lens for PlatPhorm services. That means public-safe discovery and dry-run explanation are in scope. Mutation, remediation, replay, and durable writes stay behind PLATPHORM_API_KEY on the owning service.",
        "A reader should be able to point at every stage: capability, schema, target id, expected effect, protected boundary, verifier, and receipt. If any stage is missing, the chain is not ready to execute.",
        "The AHA is that agent readiness is earned one artifact at a time."
      ],
      "url": "https://tips.platphormnews.com/entries/openclaw-toolchain-dry-run"
    },
    {
      "id": "webhook-delivery-lifecycle",
      "kind": "method",
      "kindLabel": "Method",
      "title": "A webhook is an event plus proof",
      "body": "A webhook is not just a payload arriving at a URL. It is an event contract, a signature check, a delivery receipt, a retry rule, and sometimes a protected replay. Trust the proof, not the prose summary.",
      "tag": "tooling",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A webhook should be trusted only after the event contract, signature, idempotency, and delivery proof line up.",
        "tryThis": "Design a sample webhook event and list the exact reasons a receiver should reject it before running business logic.",
        "watchFor": [
          "Raw secrets copied into public demos",
          "Replay treated as harmless because it is a retry",
          "Event summaries accepted without signature or schema proof"
        ]
      },
      "extended": [
        "The plain-language explanation is simple: one system rings another system's doorbell. The advanced version is where safety lives: who rang, what event type, what fields, what timestamp, what signature, whether it is a duplicate, and whether replay is allowed.",
        "A public framing demo can show contract, sign, deliver, verify, retry, and replay states without sending real events or exposing secrets. Raw secrets, live event creation, replay, and durable endpoint changes belong behind the protected service boundary.",
        "The AHA is that webhooks are receipts for cause and delivery. If the receipt fails, business logic should not run."
      ],
      "url": "https://tips.platphormnews.com/entries/webhook-delivery-lifecycle"
    },
    {
      "id": "cross-model-prompt-contract",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Write prompts as portable contracts",
      "body": "Prompts that work across premier models are not clever phrases. They are contracts: role, task, context, evidence, constraints, output schema, uncertainty, and stop rules.",
      "tag": "prompting",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A portable prompt is the contract all models can be graded against, not the phrase that sounds best for one model.",
        "tryThis": "Write one prompt with role, task, source ledger, constraints, output schema, uncertainty, and stop rules, then compare two model outputs field by field.",
        "watchFor": [
          "Model-specific rewrites that ruin comparison",
          "Schemas without unknown or blocked states",
          "Prompts that ask for confidence without evidence reasons"
        ]
      },
      "extended": [
        "OpenAI, Claude, Gemini, and strong open-weight models differ in features and behavior. The portable layer is the part every capable model can understand: what job it is doing, which sources count, what output shape is required, what is out of bounds, and how to say unknown.",
        "A cross-model prompt should be boring enough to test. If two models receive the same contract, you can compare schema following, receipt quality, uncertainty handling, and overreach. If you rewrite the prompt for each model, you lose the comparison.",
        "The AHA is that model routing starts with comparable failures, not brand preference."
      ],
      "url": "https://tips.platphormnews.com/entries/cross-model-prompt-contract"
    },
    {
      "id": "context-is-the-prompt",
      "kind": "method",
      "kindLabel": "Method",
      "title": "The prompt is the whole context stack",
      "body": "The model responds to more than your last sentence. It sees instructions, files, examples, retrieved chunks, memory, tools, schemas, and stop rules. That whole stack is the prompt.",
      "tag": "prompting",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "The model may ignore a fact because the context design buried, diluted, or mislabeled it.",
        "tryThis": "Build a source map before one summary and move the highest-risk constraint to the opening and closing of the context.",
        "watchFor": [
          "More context used as a substitute for better context",
          "Critical facts placed in the soft middle",
          "Retrieved chunks pasted without ranking what they prove"
        ],
        "labId": "context-position"
      },
      "extended": [
        "Context engineering is the craft of arranging the working set so the model can use the right facts at the right time. It includes what you include, what you exclude, where you place critical constraints, and how you label sources.",
        "More context can make answers worse if important facts are buried in the middle or mixed with low-value filler. Readers should practice source maps before summaries so the evidence has structure before the prose begins.",
        "The AHA is that ignored context is often a design failure, not a mysterious model mood."
      ],
      "url": "https://tips.platphormnews.com/entries/context-is-the-prompt"
    },
    {
      "id": "benchmark-time-horizon",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Benchmarks are maps of failure, not trophies",
      "body": "Modern evals are getting harder because frontier models keep saturating old tests. Treat benchmarks as maps of what still breaks, especially long tasks, coding repairs, and questions that punish overconfidence.",
      "tag": "evals",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "The most valuable benchmark output is often the broken example you can turn into a local fixture.",
        "tryThis": "Take one public benchmark-style failure and convert it into a small product-specific eval with expected safe behavior.",
        "watchFor": [
          "General scores used as production guarantees",
          "Short-answer tests used for long-running agents",
          "Benchmark examples ignored after the headline score"
        ]
      },
      "extended": [
        "A benchmark score can be useful, but the examples behind the score are usually more useful. They show what kind of task the model mishandled and what local fixture you should add before shipping.",
        "Long-task evals are especially important for agents because short answers hide drift. A model may solve one step and still lose the goal after thirty minutes of tool use, retries, and partial failures.",
        "The AHA is that a public benchmark should become a local test, not a marketing badge."
      ],
      "url": "https://tips.platphormnews.com/entries/benchmark-time-horizon"
    },
    {
      "id": "reasoning-as-search",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Reasoning is search plus checking",
      "body": "Reasoning models can spend extra compute exploring paths before answering. That can help, but the final answer still needs receipts. Longer thinking is useful only when the checks get stronger too.",
      "tag": "reliability",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Extra reasoning time creates chances to search and correct, but receipts still decide whether the answer is usable.",
        "tryThis": "Compare a fast answer and a slower reasoned answer, then score both only by tests, sources, calculations, or tool receipts.",
        "watchFor": [
          "Verbose reasoning rewarded when evidence is weak",
          "Latency spent on low-risk tasks",
          "Reasoning traces treated as proof instead of process"
        ]
      },
      "extended": [
        "The practical mental model is search. The model tries possible routes, keeps or discards candidates, and returns the answer that survives its internal process. That does not guarantee truth; it only changes how the answer was produced.",
        "Use reasoning models when uncertainty is high, task horizon is long, or the cost of a wrong first answer is meaningful. Then judge the result by tests, sources, calculations, or tool receipts instead of by the elegance of the reasoning.",
        "The AHA is that deliberation buys opportunity for correction, not immunity from error."
      ],
      "url": "https://tips.platphormnews.com/entries/reasoning-as-search"
    },
    {
      "id": "tool-protocols-over-adapters",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Prefer tool protocols over one-off adapters",
      "body": "Tool use becomes safer when the model can discover capabilities, schemas, auth boundaries, and error states through a standard protocol instead of a pile of custom glue.",
      "tag": "agents",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Protocol discovery makes tool authority visible before an agent asks to use it.",
        "tryThis": "For one tool, write the discovery metadata, input schema, public read actions, protected actions, and error states before any call.",
        "watchFor": [
          "Generic tools that do not serve the site's purpose",
          "Execution allowed before schema inspection",
          "Custom adapters with undocumented auth behavior"
        ]
      },
      "extended": [
        "One-off adapters are easy to start and hard to audit. Protocol surfaces such as MCP and agent interoperability contracts give the model and the operator a shared language for what exists, what inputs are valid, and what authority is required.",
        "The important framing move is to separate discovery from execution. A model may inspect a tool publicly without being allowed to run a protected action.",
        "The AHA is that a protocol is not bureaucracy. It is how you make tool authority visible before the model uses it."
      ],
      "url": "https://tips.platphormnews.com/entries/tool-protocols-over-adapters"
    },
    {
      "id": "prompt-injection-is-a-tool-boundary",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Prompt injection is a boundary problem",
      "body": "A prompt injection works when untrusted content gets treated like a higher-priority instruction. The repair is not just a better warning. It is separating content, command, tools, and authority.",
      "tag": "security",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Prompt injection becomes dangerous when untrusted text crosses from content into command authority.",
        "tryThis": "Place a harmless fake instruction inside retrieved content and make the model classify it as content, not a command.",
        "watchFor": [
          "Untrusted pages allowed to override system or user intent",
          "Tools exposed without least-authority checks",
          "Warnings in prompts used instead of product boundaries"
        ]
      },
      "extended": [
        "A retrieved page, webhook body, document, or user note may contain text that sounds like instructions. The model needs a rule that this text is content to analyze, not authority to obey.",
        "The safer architecture binds tools to schemas, trusted domains, explicit user intent, protected-action checks, and refusal states. The prompt can help, but the product boundary has to carry the load.",
        "The AHA is that security lives where text becomes action."
      ],
      "url": "https://tips.platphormnews.com/entries/prompt-injection-is-a-tool-boundary"
    },
    {
      "id": "source-ledger-habit",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Build a source ledger before the answer",
      "body": "A source ledger names each source, what it can prove, what it cannot prove, and when it was checked. It is the simplest way to stop a model from blending evidence, memory, and assumptions.",
      "tag": "verification",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A source ledger gives every source a job before the model starts blending evidence into prose.",
        "tryThis": "Create a four-column ledger: source, what it proves, what it cannot prove, checked-at date, then write the answer from the ledger.",
        "watchFor": [
          "Links collected without claim-level purpose",
          "Old sources used for facts likely to drift",
          "Background sources treated as direct proof"
        ]
      },
      "extended": [
        "A ledger is smaller than a report and more useful than a pile of links. It turns sources into jobs. One source may prove a date, another may prove a route contract, and another may only give background.",
        "For research trends, the ledger prevents overclaiming. A lab blog can support what the lab announced. A paper can support its tested claim. A local platform route can support current contract shape only after it is inspected.",
        "The AHA is that evidence becomes stronger when each source has a job description."
      ],
      "url": "https://tips.platphormnews.com/entries/source-ledger-habit"
    },
    {
      "id": "plain-then-precise",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Explain it like plain language, then tighten it",
      "body": "Start with the version a smart first-time reader can repeat. Then add the sharper operator version: exact terms, evidence needed, boundary, and next action. Simple first is not dumbing it down; it is building the ramp.",
      "tag": "field",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": "A clear first explanation makes the advanced one land faster.",
      "insight": {
        "aha": "Simple language is the ramp, not the ceiling. The expert version lands faster after the reader can repeat the plain one.",
        "tryThis": "Rewrite one advanced AI idea twice: first as a plain-language explanation, then as an operator checklist with evidence and boundary.",
        "watchFor": [
          "Simple explanations that remove the decision point",
          "Expert wording introduced before the reader has a handle",
          "Definitions that sound smart but do not change the next action"
        ]
      },
      "extended": [
        "A strong AI walkthrough should pass the hallway test: a reader can explain the idea to someone else without copying a paragraph. Once that works, tighten the language into the operating version.",
        "For example: plain version, the model needs receipts for important claims. Operator version, every material claim needs a source pointer, calculation, trace id, command output, or explicit assumption before it can drive a decision.",
        "The AHA is that plain language and expert language are not enemies. Plain language gives the reader a handle. Expert language gives the handle precision."
      ],
      "url": "https://tips.platphormnews.com/entries/plain-then-precise"
    },
    {
      "id": "inspect-one-claim",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Inspect one claim before judging the whole answer",
      "body": "Do not start by asking whether the AI answer feels good. Pick one important claim, ask what would prove it, and follow that evidence. One inspected claim shows more than a vague reaction to a polished paragraph.",
      "tag": "verification",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "One inspected claim can reveal whether the whole answer is evidence-shaped or just confidence-shaped.",
        "tryThis": "Pick the highest-impact sentence in a model answer and write the exact receipt that would prove or disprove it.",
        "watchFor": [
          "Judging the entire answer by tone",
          "Checking easy claims while skipping the risky one",
          "Accepting a source that only supports nearby background"
        ]
      },
      "extended": [
        "A model answer can be partly right, partly unsupported, and partly misleading at the same time. Whole-answer judgment hides that mixed state.",
        "Choose the claim with the highest impact or the weakest evidence. Then ask: what is the source, what exactly does it say, does it support this sentence, and what would change my confidence?",
        "This is the first verification habit most readers need. It turns AI review from opinion into evidence work."
      ],
      "url": "https://tips.platphormnews.com/entries/inspect-one-claim"
    },
    {
      "id": "artifact-questions",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Ask artifact questions, not vibe questions",
      "body": "A useful review question points at something visible: a cited sentence, a JSON field, a tool argument, a trace id, a route, or a screenshot. Vibe questions create opinions. Artifact questions create inspectable answers.",
      "tag": "field",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A review gets sharper when the question points to an artifact everyone can inspect together.",
        "tryThis": "Replace one vague question like is this good with three artifact questions about a source, field, route, or tool argument.",
        "watchFor": [
          "Questions that invite preferences instead of evidence",
          "Artifacts hidden behind summary language",
          "Readers unable to point at the same object"
        ]
      },
      "extended": [
        "A vibe question sounds like: is this good? An artifact question sounds like: which source supports this claim? Which field is missing? Which selector is too broad? Which trace header should follow the request?",
        "Readers ramp faster when every question has an object they can inspect. It lets them disagree productively because they are arguing over evidence, not taste.",
        "For advanced work, artifact questions become test cases. If the group cannot point at the evidence, a release gate or agent workflow should not pretend it can."
      ],
      "url": "https://tips.platphormnews.com/entries/artifact-questions"
    },
    {
      "id": "public-private-sorting",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Sort public, protected, and private before touching tools",
      "body": "Before using an AI tool or platform route, sort the action into three buckets: public read, protected action, or private data. Most unsafe automation begins when those buckets are mixed together.",
      "tag": "platform",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Most automation mistakes become visible if you sort public read, protected action, and private data before the tool runs.",
        "tryThis": "Take five routes or UI actions and label each one public read, protected action, or private data before designing the workflow.",
        "watchFor": [
          "Public dashboards that imply public write access",
          "Protected actions presented without an auth boundary",
          "Private data copied into public prompts or discovery files"
        ]
      },
      "extended": [
        "Public read means safe inspection: docs, feeds, sitemaps, health summaries, public entries, and read-only metadata. Protected action means mutation, ingestion, report generation, replay, or workflow execution that requires PLATPHORM_API_KEY. Private data means secrets, cookies, credentials, private traces, raw personal data, or anything not meant for public output.",
        "The sort should happen before the model sees the task. If the action is protected, the UI should say so. If the data is private, it should not be copied into public prompts, screenshots, feeds, or discovery files.",
        "This is a simple field exercise and a serious operator habit. It prevents a helpful assistant from becoming a careless automation system."
      ],
      "url": "https://tips.platphormnews.com/entries/public-private-sorting"
    },
    {
      "id": "first-safe-agent-plan",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Write the safe agent plan before the agent acts",
      "body": "Agents become clearer when they are framed as plans plus tools plus boundaries. Before an agent acts, write what it may inspect, what it may not touch, when it must stop, and what proof it must show.",
      "tag": "agents",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "An agent is easier to trust when its allowed moves, stop rules, and proof requirements are visible before execution.",
        "tryThis": "Write a dry-run agent plan with allowed reads, forbidden actions, stop conditions, target ids, and verification evidence.",
        "watchFor": [
          "Agent plans that skip target ids",
          "Stop conditions described only after a failure",
          "Execution summaries with no artifact proving what happened"
        ]
      },
      "extended": [
        "The agent plan should be boring. Boring is good. It names allowed read surfaces, protected actions, stop conditions, target ids, expected changes, and verification after the run.",
        "A plan without boundaries is not autonomy; it is ambiguity. A plan without proof is not execution; it is a story about execution.",
        "Readers can practice this safely with dry runs. They design the agent's allowed moves, then inspect whether the proposed tool call stays inside the plan."
      ],
      "url": "https://tips.platphormnews.com/entries/first-safe-agent-plan"
    },
    {
      "id": "definition-vs-proof",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "A definition is not proof",
      "body": "A Dictionary definition stabilizes what a word means. It does not prove that a model's claim is true. Use definitions to agree on language, then use receipts to prove claims.",
      "tag": "dictionary",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Definitions stabilize language. Receipts prove claims. Mixing those jobs creates false confidence.",
        "tryThis": "For one AI term, write the definition question and the proof question separately, then answer both with different sources.",
        "watchFor": [
          "A clean definition treated as evidence for a live claim",
          "Receipts judged without agreeing on the term",
          "Dictionary links used where a current source is required"
        ]
      },
      "extended": [
        "This confusion appears constantly in AI learning. A reader finds a clean definition for retrieval relevance and then treats that definition as evidence that a retrieved answer is relevant.",
        "The definition answers: what does this term mean? The receipt answers: what supports this claim here? Both matter, but they do different jobs.",
        "The advanced move is to pair them: define the term, inspect the artifact, then ask which receipt proves the artifact meets the definition."
      ],
      "url": "https://tips.platphormnews.com/entries/definition-vs-proof"
    },
    {
      "id": "trust-but-verify-buttons",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Every button needs a contract",
      "body": "A button should make a promise the product can keep. If it copies text, say copy. If it opens Notes, say open Notes. If it triggers a protected report, require PLATPHORM_API_KEY and show the boundary.",
      "tag": "integration",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A button is a product promise. If the action is only copy, link, or read JSON, the label should say exactly that.",
        "tryThis": "Audit three UI buttons and write what each one actually does, what it does not do, and what proof the user receives.",
        "watchFor": [
          "Buttons that imply a write happened",
          "Protected actions without PLATPHORM_API_KEY",
          "No source link behind generated or instructional content"
        ]
      },
      "extended": [
        "Buttons are tiny contracts. Bad buttons imply writes that never happened, automation that is not wired, or authority the user does not have.",
        "A good button tells the truth in the label, sends the user to the right surface, and leaves a source trail. A better button also exposes the public JSON or receipt behind the content.",
        "This is why a learning notebook should make Try this actions real: copy the exercise, open the learning surface, and expose the source entry."
      ],
      "url": "https://tips.platphormnews.com/entries/trust-but-verify-buttons"
    },
    {
      "id": "source-map-before-summary",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Build the source map before the summary",
      "body": "Before asking AI to summarize a system, list the sources it is allowed to use and what each source can prove. The summary should be the last step, not the first guess.",
      "tag": "verification",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A summary becomes safer when the source map exists before the prose starts.",
        "tryThis": "Create a source map with source, what it proves, what it cannot prove, and checked date before asking AI for a summary.",
        "watchFor": [
          "Summaries that blend live evidence with stale memory",
          "Sources used outside what they can prove",
          "No checked-at signal for drift-prone facts"
        ]
      },
      "extended": [
        "A source map is a small table: source, what it owns, what it proves, what it cannot prove, and when it was checked. For PlatPhorm surfaces, that might include network graph, sitemap index, robots, llms files, OpenAPI, MCP manifest, and RSS.",
        "Without a source map, summaries become confident blends of current facts, stale memory, and assumptions. With a source map, the model has to show where each claim came from.",
        "The AHA is that summarization becomes safer when the evidence list exists before the prose."
      ],
      "url": "https://tips.platphormnews.com/entries/source-map-before-summary"
    },
    {
      "id": "aha-from-mistake",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Turn the mistake into the AHA",
      "body": "The best framing moment is often the wrong first guess. Let readers make a safe mistake, inspect why it failed, and name the habit that would catch it next time.",
      "tag": "field",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A safe mistake can frame the repair habit more clearly than a flawless demo.",
        "tryThis": "Design one harmless failure case, let readers diagnose it, then write the habit that would catch it next time.",
        "watchFor": [
          "Mistakes that embarrass readers instead of exposing a pattern",
          "Repairs performed silently by the guide",
          "AHA moments that do not name a future action"
        ]
      },
      "extended": [
        "If every demo is polished, readers learn to admire the guide. If a safe mistake is visible, readers learn how to recover.",
        "Use mistakes that reveal a transferable pattern: a citation that is adjacent but not supportive, a tool selector that is too broad, a definition that is useful but not proof, or a status card with no source.",
        "The AHA should be the repaired habit: inspect one claim, demand a receipt, sort the boundary, or ask an artifact question."
      ],
      "url": "https://tips.platphormnews.com/entries/aha-from-mistake"
    },
    {
      "id": "readiness-red-yellow-green",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Use red, yellow, green for action readiness",
      "body": "Readers can ramp into advanced review with a simple readiness scale: green means enough evidence to proceed, yellow means inspect more, and red means stop because the boundary or evidence is wrong.",
      "tag": "field",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "Readiness labels matter when they change what happens next.",
        "tryThis": "Score one model answer green, yellow, or red and require the reason plus the next action for that color.",
        "watchFor": [
          "Green used to mean perfect instead of ready for the next step",
          "Yellow states with no inspection plan",
          "Red states that stop without explaining the boundary"
        ]
      },
      "extended": [
        "The scale works because it ties confidence to action. Green does not mean perfect. It means the evidence is good enough for the next low-risk step. Yellow means uncertainty changes what happens next. Red means the system should stop or ask for approval.",
        "Use it on model answers, tool previews, citations, glossary definitions, platform routes, and agent plans. The reader's job is to name the color and the reason.",
        "As readers get stronger, replace color with richer states: unknown, partial, protected-required, needs-review, blocked, or ready."
      ],
      "url": "https://tips.platphormnews.com/entries/readiness-red-yellow-green"
    },
    {
      "id": "term-first-fieldwork",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Frame the term before the trick",
      "body": "A reader cannot evaluate a prompt, score a citation, or review a tool call if the vocabulary is foggy. Define the key terms first, then demonstrate the technique. The trick lands only after the words are stable.",
      "tag": "field",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": "A shared glossary lowers the cost of every later explanation.",
      "insight": {
        "aha": "The vocabulary is part of the interface. If the term is unstable, the walkthrough is unstable.",
        "tryThis": "Start each framing block by naming three terms readers must understand before they watch the model behavior.",
        "watchFor": [
          "Readers copying a workflow while using the key term differently",
          "Demos that rely on undefined platform language",
          "Definitions introduced only after confusion appears"
        ]
      },
      "extended": [
        "The fastest field failure is showing the advanced move while readers are still guessing what the nouns mean. A prompt fixture, dry run, receipt, confidence bucket, and abstention branch each need a plain-language definition before the walkthrough begins.",
        "Use the Dictionary connection as a framing move: introduce the term, point to the public definition surface, ask readers to predict the failure mode, and only then run the demonstration.",
        "This changes the guide's job from explaining a magic trick to naming a repeatable mechanism. Once the term is stable, readers can transfer it to a new model, tool, or workflow."
      ],
      "url": "https://tips.platphormnews.com/entries/term-first-fieldwork"
    },
    {
      "id": "dictionary-backed-verification",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use Dictionary as the concept receipt",
      "body": "When a walkthrough depends on specialized AI vocabulary, link the term to a public Dictionary definition. The definition becomes a concept receipt: not proof that the model is right, but proof that the group is using the same meaning.",
      "tag": "dictionary",
      "date": "2026 · 06 · 30",
      "publishedAt": "2026-06-30",
      "note": null,
      "insight": {
        "aha": "A Dictionary link can be a concept receipt that proves the group is sharing a meaning before debating evidence.",
        "tryThis": "Attach a Dictionary definition to each specialized term in a field slide, notebook entry, or review checklist.",
        "watchFor": [
          "Treating a term definition as proof of a factual claim",
          "Definitions whose domain does not match the walkthrough",
          "Glossary links that point to search pages instead of concrete terms"
        ]
      },
      "extended": [
        "Concept receipts are different from fact receipts. A fact receipt supports a claim about the world. A concept receipt stabilizes the language used to discuss the claim.",
        "This matters in AI framing because terms like context window, retrieval, grounding, confidence, eval, and tool call get used casually. Casual vocabulary creates accidental disagreement.",
        "A good integration links to Dictionary for the term, links to the notebook for the operating habit, and links to Notes for the reader's private or public reflection workflow."
      ],
      "url": "https://tips.platphormnews.com/entries/dictionary-backed-verification"
    },
    {
      "id": "note-to-definition-pipeline",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Turn confused notes into dictionary candidates",
      "body": "The best glossary terms often begin as reader confusion. When several readers write the same fuzzy phrase in Notes, promote that phrase into a candidate definition instead of answering it once and losing the signal.",
      "tag": "notes",
      "date": "2026 · 06 · 29",
      "publishedAt": "2026-06-29",
      "note": null,
      "insight": {
        "aha": "Repeated reader confusion is not noise. It is demand for a clearer shared definition.",
        "tryThis": "Collect fuzzy reader phrases in Notes, group repeated phrases, and promote only reviewed candidates to Dictionary.",
        "watchFor": [
          "Publishing model-suggested definitions without human review",
          "Losing repeated reader confusion after the group ends",
          "One-off answers that never improve the shared glossary"
        ]
      },
      "extended": [
        "A field generates terminology demand in real time. If readers keep asking what a phrase means, that phrase belongs in a glossary queue.",
        "Notes is the capture layer: readers write the confusion in their own language. Dictionary is the stabilization layer: the group turns that recurring confusion into a reviewed definition.",
        "The important boundary is human approval. The model can suggest a term, summary, or definition draft, but the published Dictionary meaning should be reviewed before it becomes shared framing infrastructure."
      ],
      "url": "https://tips.platphormnews.com/entries/note-to-definition-pipeline"
    },
    {
      "id": "explain-inspect-repair-loop",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Run the explain, inspect, repair loop",
      "body": "A strong AI walkthrough has three beats: explain the mechanism, inspect a live or concrete artifact, then repair a failure. Readers remember the loop because every abstract idea earns a visible consequence.",
      "tag": "field",
      "date": "2026 · 06 · 29",
      "publishedAt": "2026-06-29",
      "note": null,
      "insight": {
        "aha": "Readers remember a concept when they see the mechanism, inspect evidence, and repair a failure themselves.",
        "tryThis": "Frame one topic with three beats: explain the mechanism, inspect a concrete artifact, then repair the broken part.",
        "watchFor": [
          "Slides that explain without giving readers an artifact to inspect",
          "Live demos with no repair step",
          "Repairs that happen silently in the guide's head"
        ]
      },
      "extended": [
        "Explaining a concept gives readers vocabulary. Inspecting an artifact gives them evidence. Repairing a failure gives them agency.",
        "For prompt reliability, the artifact might be a bad answer. For tool safety, it might be a dry-run plan. For verification, it might be a citation that points near the claim but not under it.",
        "The loop should end with an AHA checkpoint: what changed in how the reader sees the model, not just what command they copied."
      ],
      "url": "https://tips.platphormnews.com/entries/explain-inspect-repair-loop"
    },
    {
      "id": "concept-ladder",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Climb from word to workflow",
      "body": "Do not leave a concept at the definition stage. Climb it through four rungs: word, example, failure, workflow. A reader understands a term when they can use it to decide what to do next.",
      "tag": "field",
      "date": "2026 · 06 · 28",
      "publishedAt": "2026-06-28",
      "note": null,
      "insight": {
        "aha": "A term becomes operational only when the reader can use it to choose the next move.",
        "tryThis": "For one concept, write the word, a clean example, a failure example, and the workflow decision it changes.",
        "watchFor": [
          "Definitions that never reach a practical example",
          "Examples that do not show the failure mode",
          "Readers who can repeat the word but cannot act on it"
        ]
      },
      "extended": [
        "The word rung names the concept. The example rung shows it in a clean case. The failure rung shows why it matters. The workflow rung turns it into a repeatable decision.",
        "Dictionary helps with the word rung. The notebook helps with the example and failure rungs. Notes helps readers turn the workflow rung into their own operating habit.",
        "If a walkthrough stops at a definition, it is reference material. If it reaches workflow, it becomes practice."
      ],
      "url": "https://tips.platphormnews.com/entries/concept-ladder"
    },
    {
      "id": "glossary-before-demo",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Put the glossary before the demo",
      "body": "A live demo creates cognitive load. Do the vocabulary work first so readers can spend the demo watching the model behavior instead of decoding the guide's words.",
      "tag": "dictionary",
      "date": "2026 · 06 · 28",
      "publishedAt": "2026-06-28",
      "note": null,
      "insight": {
        "aha": "The demo is where readers should watch behavior, not decode vocabulary under pressure.",
        "tryThis": "List the walkthrough glossary before the first live output and link each term to Dictionary when a public definition exists.",
        "watchFor": [
          "Cognitive overload from new terms during the demo",
          "Guide-specific jargon that has no shared reference",
          "Terms explained differently in slides, notes, and discussion"
        ]
      },
      "extended": [
        "Before a retrieval demo, define retrieval, relevance, chunk, contradiction, and receipt. Before a tool demo, define dry run, target id, protected action, and rollback.",
        "The definitions do not need to be long. They need to be visible and shared.",
        "This is where a Dictionary link does real work. It gives the group a stable reference outside the slide, the notebook entry, and the guide's memory."
      ],
      "url": "https://tips.platphormnews.com/entries/glossary-before-demo"
    },
    {
      "id": "human-approval-queue",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Keep glossary publishing human-approved",
      "body": "AI can propose a definition, but shared language deserves review. Treat Dictionary publishing like a small release: draft, inspect, approve, publish, and leave provenance behind.",
      "tag": "governance",
      "date": "2026 · 06 · 27",
      "publishedAt": "2026-06-27",
      "note": null,
      "insight": {
        "aha": "A bad shared definition compounds because future walkthroughs and workflows inherit it.",
        "tryThis": "Stage candidate glossary definitions as drafts, require human approval, and include source or scope notes before publishing.",
        "watchFor": [
          "Model-written definitions treated as approved knowledge",
          "No provenance for why a definition changed",
          "Technically correct definitions that miss the field audience"
        ]
      },
      "extended": [
        "The risk is subtle. A bad definition does not only misstate one answer; it trains future readers to reason with the wrong frame.",
        "A human approval queue catches invented authority, missing caveats, audience mismatch, and definitions that are technically correct but useless in practice.",
        "The pipeline is still fast. Notes can stage the reader language, AI can draft the candidate, Dictionary can expose the reviewed term, and the notebook can link the term back into walkthroughs."
      ],
      "url": "https://tips.platphormnews.com/entries/human-approval-queue"
    },
    {
      "id": "integration-contract-cards",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Use integration cards instead of vague platform links",
      "body": "A cross-site link should explain what the target service owns, what public data is safe to read, what requires PLATPHORM_API_KEY, and what the current page does not do.",
      "tag": "integration",
      "date": "2026 · 06 · 27",
      "publishedAt": "2026-06-27",
      "note": "A link without a contract is just navigation.",
      "insight": {
        "aha": "A cross-site link is safer when it says what the target owns and what this page will not do.",
        "tryThis": "Write each integration card with owner, public reads, protected actions, and handoff links before adding buttons.",
        "watchFor": [
          "Buttons implying a write happened when only navigation occurred",
          "Protected actions presented as public workflows",
          "Generic platform links without a product-specific handoff"
        ]
      },
      "extended": [
        "Dictionary owns public definitions and concept lookup. Notes owns learning capture, term detection, and note analysis previews. This notebook owns walkthroughs, entries, and framing flows.",
        "A good integration card states the handoff in plain language: open the definition, capture a note, preview term detection, or review a workflow template.",
        "It should also name the boundary. If this site is not posting to Dictionary or Notes, the UI should not imply that a write happened."
      ],
      "url": "https://tips.platphormnews.com/entries/integration-contract-cards"
    },
    {
      "id": "aha-checkpoints",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Stop for AHA checkpoints",
      "body": "A walkthrough is not complete when the guide finishes the content. Stop at the moment where the reader's model should change and ask them to say what they see differently now.",
      "tag": "field",
      "date": "2026 · 06 · 26",
      "publishedAt": "2026-06-26",
      "note": null,
      "insight": {
        "aha": "The AHA moment is the measurable change in what the reader knows how to inspect next.",
        "tryThis": "Pause after each major concept and ask readers to name the first artifact they would inspect now.",
        "watchFor": [
          "Readers agreeing verbally without changing their review behavior",
          "Checkpoints that ask for feelings instead of observable next moves",
          "Too many concepts between reflection points"
        ]
      },
      "extended": [
        "AHA checkpoints are small but powerful. They ask readers to name the shift: from answer to evidence, from prompt to contract, from tool to action, from confidence to decision.",
        "The checkpoint should be concrete enough to grade informally. If readers cannot say what they would inspect next, the AHA moment did not land yet.",
        "This is why the notebook includes AHA text beside entries instead of hiding it in guide notes."
      ],
      "url": "https://tips.platphormnews.com/entries/aha-checkpoints"
    },
    {
      "id": "notes-as-observation-log",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Use Notes as an observation log",
      "body": "When readers inspect model behavior, ask them to write observations before conclusions. Notes should capture what happened, what surprised them, and what term they need clarified.",
      "tag": "notes",
      "date": "2026 · 06 · 26",
      "publishedAt": "2026-06-26",
      "note": null,
      "insight": {
        "aha": "Observation-first notes preserve the evidence before the reader writes a story about it.",
        "tryThis": "Use the format I saw, I expected, I think it means, and I need a definition for after every demo.",
        "watchFor": [
          "Conclusions recorded without the artifact that caused them",
          "Surprising behavior erased by a polished summary",
          "Term confusion captured nowhere reusable"
        ]
      },
      "extended": [
        "Observation-first notes reduce hindsight storytelling. The reader writes the low-confidence token, unsupported claim, weird citation, or broad tool selector before explaining it away.",
        "Those observations become better prompts for review, better term candidates for Dictionary, and better discussion material for a field.",
        "The simple format is: I saw, I expected, I think it means, I need a definition for."
      ],
      "url": "https://tips.platphormnews.com/entries/notes-as-observation-log"
    },
    {
      "id": "dictionary-provenance-check",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Check provenance before framing a term",
      "body": "If a term definition will anchor a walkthrough, inspect its source and scope first. A definition can be useful for one domain and misleading in another.",
      "tag": "dictionary",
      "date": "2026 · 06 · 25",
      "publishedAt": "2026-06-25",
      "note": null,
      "insight": {
        "aha": "A definition is scoped evidence. It helps only when its source and domain match the walkthrough.",
        "tryThis": "Before framing a term, inspect whether the definition names the domain, source, and intended audience.",
        "watchFor": [
          "One domain's meaning reused in a different workflow",
          "Definitions with no source or scope signal",
          "Treating Dictionary as a substitute for current behavior checks"
        ]
      },
      "extended": [
        "Definitions have context. A release-engineering meaning of gate is not the same as a field meaning or a safety-policy meaning.",
        "Before framing from a term, check whether the definition names the domain, source, and intended audience. If the provenance is weak, treat it as a draft or discussion prompt.",
        "This keeps Dictionary integration honest: it supports shared language, but it does not replace judgment."
      ],
      "url": "https://tips.platphormnews.com/entries/dictionary-provenance-check"
    },
    {
      "id": "socratic-eval-prompts",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Use Socratic eval prompts in group",
      "body": "Instead of asking whether the answer is good, ask which claim would fail first, which receipt is missing, which term is undefined, and what evidence would change the decision.",
      "tag": "evals",
      "date": "2026 · 06 · 25",
      "publishedAt": "2026-06-25",
      "note": null,
      "insight": {
        "aha": "The question shapes the habit. Ask about failure, missing receipts, and next evidence instead of asking if it is good.",
        "tryThis": "Give readers four prompts: what fails first, what receipt is missing, what term is undefined, and what evidence changes this.",
        "watchFor": [
          "Eval questions that invite taste instead of inspection",
          "Readers scoring outputs without citing artifacts",
          "Questions that do not transfer to another workflow"
        ]
      },
      "extended": [
        "Socratic eval prompts frame readers to inspect systems instead of merely reacting to outputs. The question shapes the habit.",
        "Good field eval prompts are short, reusable, and attached to visible artifacts. They work on a model answer, a tool plan, a note, a definition, or a citation list.",
        "The strongest prompt is often: what would you need to see before you let this action run?"
      ],
      "url": "https://tips.platphormnews.com/entries/socratic-eval-prompts"
    },
    {
      "id": "misconception-map",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Map misconceptions as content gaps",
      "body": "Repeated misunderstandings are not interruptions; they are product signals. Track them as missing entries, missing definitions, missing examples, or missing field exercises.",
      "tag": "field",
      "date": "2026 · 06 · 24",
      "publishedAt": "2026-06-24",
      "note": null,
      "insight": {
        "aha": "Misconceptions are content backlog with evidence attached.",
        "tryThis": "Track repeated misunderstandings as missing entries, missing definitions, missing examples, or missing exercises.",
        "watchFor": [
          "Answering the same confusion repeatedly without improving content",
          "Misconceptions blamed on readers instead of unclear material",
          "No owner for converting group friction into curriculum updates"
        ]
      },
      "extended": [
        "A misconception map turns framing friction into backlog. If readers confuse confidence with correctness, add an entry. If they confuse retrieval with relevance, add a definition. If they over-trust citations, add a failure case.",
        "The map should include the mistaken belief, the correction, the artifact that reveals it, and the next content improvement.",
        "This is how a field notebook becomes a living curriculum instead of a static list of tips."
      ],
      "url": "https://tips.platphormnews.com/entries/misconception-map"
    },
    {
      "id": "focus-fullscreen-mode",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Use full-screen mode for shared attention",
      "body": "A framing surface should remove sidebar noise when the room needs one idea. Full-screen mode turns the notebook into a slide-like sequence without losing links back to entries, Dictionary, and Notes.",
      "tag": "field",
      "date": "2026 · 06 · 24",
      "publishedAt": "2026-06-24",
      "note": null,
      "insight": {
        "aha": "Full-screen mode is useful when it narrows the room to one concept, one artifact, and one next action.",
        "tryThis": "Use full-screen mode for kickoff, live demo, recap, or AHA checkpoint, then return to the notebook for details.",
        "watchFor": [
          "Presentation mode that hides links readers need after group",
          "Large decorative screens with no workflow action",
          "Too much text on a shared framing slide"
        ]
      },
      "extended": [
        "Full-screen mode is not a marketing hero. It is a field tool: large type, clear current walkthrough, one AHA checkpoint, and one action at a time.",
        "The best version preserves the operating surface. Readers can still open the related entry, check the Dictionary term, or capture a note after the slide lands.",
        "Use it when shared attention matters: kickoff, recap, live demo, or review."
      ],
      "url": "https://tips.platphormnews.com/entries/focus-fullscreen-mode"
    },
    {
      "id": "glossary-drift-watch",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Watch for glossary drift",
      "body": "Terms drift when teams reuse them in new workflows. Schedule periodic review for field terms, Dictionary definitions, and notebook entries so old wording does not frame stale behavior.",
      "tag": "governance",
      "date": "2026 · 06 · 23",
      "publishedAt": "2026-06-23",
      "note": null,
      "insight": {
        "aha": "Shared vocabulary is a dependency, and dependencies drift.",
        "tryThis": "Review field terms after model, tool, or platform boundary changes and update Dictionary plus notebook links together.",
        "watchFor": [
          "Definitions that describe a previous platform state",
          "Entries framing examples that no longer reproduce",
          "Protected/public boundaries changing without glossary updates"
        ]
      },
      "extended": [
        "AI vocabulary moves quickly. A definition that was clear during one model generation can become misleading after tools, providers, or platform boundaries change.",
        "Drift review asks whether the term still matches current behavior, whether the examples still reproduce, and whether the protected/public boundary changed.",
        "The repair is small but important: update the definition, update the entry, and update any field checkpoint that depends on it."
      ],
      "url": "https://tips.platphormnews.com/entries/glossary-drift-watch"
    },
    {
      "id": "self-quiz-cards",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Turn entries into self-quiz cards",
      "body": "Every entry should produce a recall question, an artifact question, and a transfer question. If readers can answer all three, the insight has moved from reading to practice.",
      "tag": "field",
      "date": "2026 · 06 · 23",
      "publishedAt": "2026-06-23",
      "note": null,
      "insight": {
        "aha": "Learning sticks when recall, artifact inspection, and transfer all work.",
        "tryThis": "Write one recall question, one artifact question, and one transfer question for each high-value entry.",
        "watchFor": [
          "Quizzes that only ask for memorized definitions",
          "No concrete artifact in the question",
          "Readers passing the quiz but failing to transfer the habit"
        ]
      },
      "extended": [
        "Recall asks for the idea. Artifact asks readers to use the idea on a concrete output. Transfer asks whether they can spot the same pattern in a different workflow.",
        "For receipts: what is a receipt, which claim lacks one, and where else would you require one? For dry runs: what is the action preview, which selector is too broad, and what protected action should stop?",
        "Self-quiz cards make the notebook useful between groupes, not only during live framing."
      ],
      "url": "https://tips.platphormnews.com/entries/self-quiz-cards"
    },
    {
      "id": "retrieval-relevance",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Score retrieved context before you trust the answer",
      "body": "A retrieval system can hand the model a pile of documents and still miss the actual question. Score each chunk for direct relevance, answer support, and contradiction before you let the final answer inherit authority from the word 'retrieved'.",
      "tag": "verification",
      "date": "2026 · 06 · 28",
      "publishedAt": "2026-06-28",
      "note": "Retrieved is not the same thing as relevant.",
      "insight": {
        "aha": "Retrieval only proves that documents were fetched. It does not prove the fetched text answers the question.",
        "tryThis": "Label each retrieved chunk as direct support, background, contradiction, or irrelevant before reading the final answer.",
        "watchFor": [
          "Answers citing adjacent background as if it were direct support",
          "Contradictory chunks hidden by smooth synthesis",
          "High source count used as a substitute for relevance"
        ]
      },
      "extended": [
        "RAG failures often look like model failures because the model speaks with the confidence of the context it was given. The first move is to separate retrieval quality from generation quality.",
        "Give each chunk three labels: directly answers, adjacent background, or contradiction. The answer should cite directly answering chunks first and name contradictions instead of smoothing them away.",
        "A good retrieval review is boring and mechanical. It asks whether the evidence was even in the room before debating whether the model reasoned over it correctly."
      ],
      "url": "https://tips.platphormnews.com/entries/retrieval-relevance"
    },
    {
      "id": "schema-first-output",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Design the output schema before the prompt",
      "body": "When the output has fields, types, allowed values, and failure states, the prompt stops being a prose wish and becomes an interface contract. The model has less room to improvise because the answer has a shape to satisfy.",
      "tag": "reliability",
      "date": "2026 · 06 · 24",
      "publishedAt": "2026-06-24",
      "note": null,
      "insight": {
        "aha": "A schema turns a vague prompt into an interface contract with explicit absence states.",
        "tryThis": "Write the JSON fields, allowed values, evidence pointers, and unknown states before drafting the prompt.",
        "watchFor": [
          "Required fields that force the model to invent missing data",
          "Enums that do not include blocked, unknown, or partial",
          "Fields whose consumer or decision impact is unclear"
        ]
      },
      "extended": [
        "A schema makes ambiguity visible. If you cannot name the field, type, and allowed absence state, you probably do not know what you are asking the model to produce.",
        "Start with the downstream consumer. Does it need a label, a span, a confidence bucket, a source pointer, or an abstention? Write that contract first and then prompt the model to fill it.",
        "The aha is that schemas are not just for machines. They force human reviewers to decide what counts as complete, partial, unknown, and unsafe."
      ],
      "url": "https://tips.platphormnews.com/entries/schema-first-output"
    },
    {
      "id": "eval-sandwich",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use the eval sandwich: before, during, after",
      "body": "One eval at the end is a smoke alarm, not a control system. Run a small eval before the change, a targeted eval during the change, and a regression eval after. The sandwich catches drift while the work is still cheap to fix.",
      "tag": "evals",
      "date": "2026 · 06 · 20",
      "publishedAt": "2026-06-20",
      "note": "The middle eval is where most prompt regressions get caught.",
      "insight": {
        "aha": "The most valuable eval is often the small one you run while the prompt is still being edited.",
        "tryThis": "Run a baseline set before the change, five targeted fixtures during the change, and a regression set after.",
        "watchFor": [
          "Only testing the behavior you intended to improve",
          "Skipping refusal and edge fixtures after style changes",
          "Treating one green benchmark as proof of production safety"
        ]
      },
      "extended": [
        "Before-change evals establish the baseline you are trying not to lose. During-change evals are small and sharp: the five examples most likely to break because of the edit. After-change evals make sure the fix did not damage neighboring behavior.",
        "This is especially useful for system prompt work because every instruction edit has a shadow. You improve one behavior and accidentally move refusal, tone, verbosity, or citation discipline.",
        "Treat the eval sandwich as a change-management ritual. It is less glamorous than a benchmark, but it is the thing that keeps production behavior from drifting by inches."
      ],
      "url": "https://tips.platphormnews.com/entries/eval-sandwich"
    },
    {
      "id": "tool-dry-run",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Dry-run tool calls before letting them mutate anything",
      "body": "A tool call is not just an answer; it is an action. Before a model can send, delete, replay, publish, or spend, make it produce a dry-run plan with inputs, target, expected effect, and rollback path.",
      "tag": "tooling",
      "date": "2026 · 06 · 14",
      "publishedAt": "2026-06-14",
      "note": null,
      "insight": {
        "aha": "A tool call should become inspectable before it becomes irreversible.",
        "tryThis": "Require action preview, target ids, expected effects, refusal conditions, and rollback notes before execution.",
        "watchFor": [
          "Tool arguments that include broad or ambiguous selectors",
          "Mutation plans without a verification step",
          "The model treating permission to plan as permission to execute"
        ]
      },
      "extended": [
        "Tool use changes the risk profile of a model. The model can be wrong in the world, not just wrong in text. The safe pattern is preview, inspect, authorize, execute, verify.",
        "The dry run should include exactly what will be called, what identifiers will be touched, which fields will change, and what success will look like. If the model cannot state those plainly, it should not run the tool.",
        "The best dry runs also include a refusal branch. They say what condition would stop execution and what evidence would be needed to proceed."
      ],
      "url": "https://tips.platphormnews.com/entries/tool-dry-run"
    },
    {
      "id": "citation-triangulation",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Triangulate citations instead of trusting the first source",
      "body": "One citation can prove that a sentence has a source-shaped object nearby. Two independent citations can show whether the claim survives contact with another account. For consequential facts, triangulation beats citation decoration.",
      "tag": "verification",
      "date": "2026 · 06 · 08",
      "publishedAt": "2026-06-08",
      "note": null,
      "insight": {
        "aha": "A second independent source often reveals whether a citation supports the claim or merely resembles it.",
        "tryThis": "Triangulate dates, quotes, benchmarks, allegations, and high-impact facts before presenting them as settled.",
        "watchFor": [
          "Citations that support a nearby but different claim",
          "Two sources that repeat the same upstream source",
          "Disagreements collapsed into a false consensus"
        ]
      },
      "extended": [
        "Citation checking should ask three questions: does the source exist, does it support the exact claim, and would another independent source phrase the same claim the same way?",
        "When sources disagree, the disagreement is the content. Do not ask the model to hide the conflict behind a confident synthesis. Ask it to name the split and explain what would settle it.",
        "Triangulation is not needed for every sentence. Reserve it for claims that drive decisions: dates, quotes, prices, medical or legal facts, benchmarks, and allegations."
      ],
      "url": "https://tips.platphormnews.com/entries/citation-triangulation"
    },
    {
      "id": "red-team-mutants",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Red-team prompts with harmless mutants",
      "body": "If a safety or quality rule only works for the exact phrase you tested, you do not have a rule. Create harmless mutants that preserve intent while changing tone, language, order, and indirection.",
      "tag": "evals",
      "date": "2026 · 05 · 31",
      "publishedAt": "2026-05-31",
      "note": null,
      "insight": {
        "aha": "A boundary that only holds for one phrasing is a memorized example, not a reliable rule.",
        "tryThis": "Generate harmless variants that preserve intent while changing tone, order, indirection, language, and role framing.",
        "watchFor": [
          "Safety behavior that fails when the user sounds polite",
          "Allowed prompts that become over-refused after hardening",
          "Fixtures that mutate the danger instead of just the wrapper"
        ]
      },
      "extended": [
        "Prompt boundaries are brittle when tests are too literal. A model may refuse the obvious bad phrasing and comply with the polite version, the translated version, or the version hidden inside a roleplay.",
        "Mutants make that brittleness visible without adding new dangerous content. They perturb the wrapper, not the underlying safety category.",
        "Use them for both sides of the boundary: prompts that should be refused and prompts that should remain allowed. Over-refusal is a product bug too."
      ],
      "url": "https://tips.platphormnews.com/entries/red-team-mutants"
    },
    {
      "id": "semantic-diff",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Diff the meaning, not just the text",
      "body": "A prompt edit can look tiny and change the whole behavior. Run a semantic diff that lists new obligations, removed constraints, softened verbs, and changed authority before shipping instruction changes.",
      "tag": "prompting",
      "date": "2026 · 05 · 18",
      "publishedAt": "2026-05-18",
      "note": "A one-word modal change can be a policy change.",
      "insight": {
        "aha": "The smallest text diff can be the biggest behavioral diff when it changes authority, scope, or obligation.",
        "tryThis": "Review prompt edits for new duties, removed constraints, softened verbs, and examples that imply new policy.",
        "watchFor": [
          "May, should, and must changes hidden in wording cleanup",
          "Examples that contradict the written rule",
          "Output contracts changed without matching tests"
        ]
      },
      "extended": [
        "Text diff says what characters changed. Semantic diff says what the model is now being asked to believe, prioritize, refuse, or produce. That is the diff that matters for behavior.",
        "Look for modal verbs, scope words, exception clauses, examples that imply new rules, and output format changes. These are the places where small edits become big runtime differences.",
        "A useful semantic diff ends with a test plan: which fixtures should change, which must not change, and which new example proves the edit worked."
      ],
      "url": "https://tips.platphormnews.com/entries/semantic-diff"
    },
    {
      "id": "latency-budget",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Spend latency where uncertainty is highest",
      "body": "Do not add slow verification everywhere. Spend extra model calls, retrieval, self-consistency, or human review only where the first pass shows low confidence, high impact, or weak evidence.",
      "tag": "reliability",
      "date": "2026 · 05 · 09",
      "publishedAt": "2026-05-09",
      "note": null,
      "insight": {
        "aha": "Careful does not have to mean slow everywhere. Verification can wake up only where risk wakes it up.",
        "tryThis": "Escalate to extra checks when confidence is low, evidence is weak, impact is high, or an action is protected.",
        "watchFor": [
          "Uniformly expensive checks on low-risk tasks",
          "Fast paths that ignore missing evidence",
          "Latency budgets without explicit escalation triggers"
        ]
      },
      "extended": [
        "Reliable AI systems are often cascades. Cheap checks run first; expensive checks wake up only when the situation deserves them. This keeps the product fast without pretending every answer has equal risk.",
        "A practical budget has triggers: low logprob margin, missing receipt, protected action, high-dollar decision, policy boundary, or user-visible publication.",
        "The aha is that latency can be evidence-driven. You do not need to choose between always fast and always careful."
      ],
      "url": "https://tips.platphormnews.com/entries/latency-budget"
    },
    {
      "id": "model-routing",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Route tasks by failure mode, not brand name",
      "body": "The best model for a job is the one whose failure mode you can tolerate. Route extraction, synthesis, coding, refusal review, and creative exploration by observed behavior, not by leaderboard aura.",
      "tag": "reliability",
      "date": "2026 · 04 · 26",
      "publishedAt": "2026-04-26",
      "note": null,
      "insight": {
        "aha": "Routing by failure mode is more useful than routing by reputation because every model breaks differently.",
        "tryThis": "Build a route table from observed task fixtures: extraction, synthesis, coding, refusal review, and long-context use.",
        "watchFor": [
          "Leaderboards used as a substitute for local fixtures",
          "Model routes that cannot be changed without code edits",
          "Ignoring behavior drift after model updates"
        ]
      },
      "extended": [
        "Model routing is usually framed as cost or quality. The more useful frame is failure. Which model omits caveats, over-refuses, invents sources, follows schemas, or handles long contexts under pressure?",
        "Build small route tests around the jobs you actually run. A model that wins general reasoning may still be the wrong choice for structured extraction if it casually fills unknown fields.",
        "Keep routing reversible. When model behavior shifts, the route table should be an operational setting backed by evidence, not a belief system."
      ],
      "url": "https://tips.platphormnews.com/entries/model-routing"
    },
    {
      "id": "memory-hygiene",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Treat memory as evidence with an expiration date",
      "body": "Memory makes an agent feel continuous, but stale memory can be worse than no memory. Store decisions, constraints, and stable preferences; refresh facts that drift; never let memory outrank current evidence.",
      "tag": "verification",
      "date": "2026 · 04 · 18",
      "publishedAt": "2026-04-18",
      "note": null,
      "insight": {
        "aha": "Agent memory is a cache. Useful caches have scope, freshness, and invalidation rules.",
        "tryThis": "Store stable decisions and preferences, but re-check drift-prone facts before acting on them.",
        "watchFor": [
          "Old status presented as current proof",
          "Private residue stored when only workflow shape was needed",
          "Memory outranking live repo, source, or user evidence"
        ]
      },
      "extended": [
        "Good memory is scoped. It records what the user decided, what a repo convention is, and which risks were already found. Bad memory stores private residue, stale status, or facts that should be rechecked.",
        "Every memory-derived claim should answer two questions: when was this learned, and how likely is it to have changed? If the answer is 'recently unstable,' verify before acting.",
        "The aha is that memory is not context magic. It is a cache, and caches need invalidation rules."
      ],
      "url": "https://tips.platphormnews.com/entries/memory-hygiene"
    },
    {
      "id": "abstention-design",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Design abstention as a first-class output",
      "body": "If the only valid-looking answer is a filled answer, the model will fill one. Give it a clean way to say unknown, insufficient evidence, unsafe, or needs human review, and make those states useful.",
      "tag": "reliability",
      "date": "2026 · 04 · 03",
      "publishedAt": "2026-04-03",
      "note": null,
      "insight": {
        "aha": "A model fills blanks when the product has no respected way to stop.",
        "tryThis": "Make unknown, partial, blocked, protected-required, and needs-review states valid outputs with next actions.",
        "watchFor": [
          "Schemas where every field must be filled even when evidence is absent",
          "Refusals that leave the user without a useful next step",
          "Unknown states treated as errors instead of designed outcomes"
        ]
      },
      "extended": [
        "Abstention fails when it feels like an error. It works when it is a designed branch with a reason, missing evidence, and next action. The user should know what changed from answerable to not answerable.",
        "Use explicit output states: answered, partial, unknown, blocked, protected-required, and needs-review. Each state should carry what evidence exists and what evidence is missing.",
        "This is how you prevent graceful prose from hiding a dead end. The model can stop without leaving the user stuck."
      ],
      "url": "https://tips.platphormnews.com/entries/abstention-design"
    },
    {
      "id": "confidence-buckets",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use confidence buckets, not fake precision",
      "body": "A model saying 87% confident usually means it learned that numbers sound calibrated. Buckets like high, medium, low, and unknown force confidence to be tied to evidence quality and decision impact.",
      "tag": "verification",
      "date": "2026 · 03 · 21",
      "publishedAt": "2026-03-21",
      "note": null,
      "insight": {
        "aha": "Confidence is useful when it changes what happens next, not when it looks mathematically precise.",
        "tryThis": "Use high, medium, low, and unknown buckets tied to evidence type, conflict level, and review action.",
        "watchFor": [
          "Percentages that are not calibrated against historical outcomes",
          "Confidence labels without evidence reasons",
          "High confidence on claims with no direct receipt"
        ]
      },
      "extended": [
        "Precise confidence numbers look scientific and often are not. Unless they are tied to a calibrated model or measured historical error, they are mostly theater.",
        "Buckets work better in operator workflows because they can map to action: high can publish, medium can request a receipt, low can escalate, unknown can abstain.",
        "The bucket should cite the reason: direct source found, conflicting source found, no source found, or model-only inference. That reason matters more than the label."
      ],
      "url": "https://tips.platphormnews.com/entries/confidence-buckets"
    },
    {
      "id": "counter-evidence",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Ask for counter-evidence before confidence",
      "body": "A model that only explains why its answer is right will happily polish a mistake. Ask it to list the strongest evidence against its answer before it scores confidence. The missing objection is often the thing that saves you.",
      "tag": "reliability",
      "date": "2026 · 06 · 18",
      "publishedAt": "2026-06-18",
      "note": "Confidence after counter-evidence is more useful than confidence after a sales pitch.",
      "insight": {
        "aha": "The model is usually best at self-correction before it has been rewarded for sounding certain.",
        "tryThis": "Ask for the answer, the strongest objection, what evidence would change the answer, and then confidence.",
        "watchFor": [
          "Objections that restate the answer instead of challenging it",
          "Confidence that stays high after missing evidence appears",
          "A final answer that ignores its own counter-evidence"
        ],
        "labId": "counter-evidence"
      },
      "extended": [
        "The useful move is not asking the model to be uncertain. The useful move is forcing it to search for the best case against itself while the answer is still provisional.",
        "A simple pattern: draft the answer, list disconfirming evidence, name what would change the answer, then assign confidence. The confidence number becomes attached to evidence quality instead of verbal smoothness.",
        "This is especially helpful for research summaries, legal-ish interpretation, data diagnosis, and anything where one missing constraint can flip the conclusion."
      ],
      "url": "https://tips.platphormnews.com/entries/counter-evidence"
    },
    {
      "id": "receipts",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Turn every important claim into a receipt",
      "body": "For high-stakes answers, make the model attach each claim to a source, calculation, line number, trace id, or explicit assumption. Unsupported claims do not disappear, but they become visible enough to reject.",
      "tag": "verification",
      "date": "2026 · 05 · 27",
      "publishedAt": "2026-05-27",
      "note": null,
      "insight": {
        "aha": "A citation is not decoration. It is a handle you can pull to see whether the sentence is load-bearing.",
        "tryThis": "Make every claim end with one receipt: source, row, command, calculation, trace id, or explicit assumption.",
        "watchFor": [
          "Receipts that point to a broad document instead of the claim",
          "Numbers without denominators",
          "Source links that support nearby context but not the sentence itself"
        ],
        "labId": "receipts"
      },
      "extended": [
        "Models are good at moving from evidence to prose. They are also good at producing prose that looks like it came from evidence. The receipt requirement separates those two behaviors.",
        "The receipt can be a citation, a row count, a command output line, a test name, or a declared assumption. The format matters less than the discipline: every claim has to point somewhere.",
        "When the model cannot produce a receipt, that is not failure. That is the system doing its job and showing you where judgment is still needed."
      ],
      "url": "https://tips.platphormnews.com/entries/receipts"
    },
    {
      "id": "short-system-prompts",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Keep the system prompt short enough to audit",
      "body": "A giant instruction stack feels powerful until nobody can tell which rule caused the behavior. Keep the non-negotiables small, move task detail into the user prompt, and test the system prompt like code.",
      "tag": "prompting",
      "date": "2026 · 05 · 03",
      "publishedAt": "2026-05-03",
      "note": "If you cannot diff it cleanly, you cannot debug it cleanly.",
      "insight": {
        "aha": "A system prompt is product code. If it is too long to review, it is too long to trust.",
        "tryThis": "Rewrite the system prompt into role, hard boundary, output contract, and escalation rule.",
        "watchFor": [
          "Repeated style instructions that fight each other",
          "Hidden policy changes bundled into wording edits",
          "Task detail that belongs in user input rather than permanent rules"
        ]
      },
      "extended": [
        "System prompts work best as durable operating constraints, not as a dumping ground for every possible preference. When the prompt grows without structure, the model starts resolving conflicts in ways you cannot predict.",
        "Split the prompt into policy, role, output contract, and refusal boundary. Then write a small regression set that exercises each section. You will catch more problems with five targeted tests than with another page of instructions."
      ],
      "url": "https://tips.platphormnews.com/entries/short-system-prompts"
    },
    {
      "id": "refusal-fixtures",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Use refusal boundaries as test fixtures",
      "body": "Do not only test the happy path. Save examples that should be refused, partially answered, or redirected, then run them every time you change instructions. Safety behavior drifts just like product behavior.",
      "tag": "evals",
      "date": "2026 · 04 · 12",
      "publishedAt": "2026-04-12",
      "note": null,
      "insight": {
        "aha": "Safety quality is not whether the model refuses. It is whether it refuses at the right boundary.",
        "tryThis": "Keep allowed, disallowed, and allowed-with-constraints prompts as fixtures and run them after prompt edits.",
        "watchFor": [
          "Over-refusal on harmless transformed versions",
          "Under-refusal when the same intent is phrased politely",
          "Responses that refuse but fail to offer a safe next step"
        ]
      },
      "extended": [
        "Most prompt tests focus on whether the model can complete the intended workflow. That misses the other half of the product: whether it handles edge requests without over-refusing, leaking private context, or inventing authority it does not have.",
        "Build a small fixture set with three buckets: allowed, disallowed, and allowed-with-constraints. A good model response should land in the right bucket and explain the usable next step.",
        "This turns safety from a vibe into a regression target. When a prompt edit changes the refusal boundary, you see it immediately."
      ],
      "url": "https://tips.platphormnews.com/entries/refusal-fixtures"
    },
    {
      "id": "logprobs",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Read the logprobs, not the answer",
      "body": "The text a model gives you is the tip of the iceberg. Ask the API for token logprobs and you can see where it was confident versus where it basically flipped a coin. A fluent sentence built on 51% tokens is a guess wearing a suit.",
      "tag": "interpretability",
      "date": "2025 · 11 · 02",
      "publishedAt": "2025-11-02",
      "note": "Confidence ≠ correctness. But low confidence is a great place to look for hallucinations.",
      "insight": {
        "aha": "The final text is only the winning token path. The uncertainty is still visible in the runners-up.",
        "tryThis": "Render low-margin tokens first, especially names, dates, citations, and first tokens after a policy boundary.",
        "watchFor": [
          "Fluent spans built from low-confidence token choices",
          "Nearly tied alternatives around entities",
          "A confident tone hiding a fragile probability margin"
        ],
        "labId": "logprobs"
      },
      "extended": [
        "Every token a model emits comes with a probability distribution over the whole vocabulary. The decoded text only shows you the winner. The logprobs show you the race.",
        "When you pull them back, scan for the spots where the top token barely beat the runner-up. Those are the seams. Names, dates, citations, and the first token of a refusal are where you most often find a coin-flip dressed up as a confident sentence.",
        "A practical loop: request the top 5 logprobs per token, render them as a heatmap over the output, and read the cold spots first. That is usually where the hallucination lives."
      ],
      "url": "https://tips.platphormnews.com/entries/logprobs"
    },
    {
      "id": "think-out-loud",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Make it think before it answers",
      "body": "Put the reasoning before the conclusion, never after. If you ask for the answer first and the explanation second, the explanation is just a story it invents to justify a choice it already made. Order matters more than wording.",
      "tag": "prompting",
      "date": "2025 · 10 · 28",
      "publishedAt": "2025-10-28",
      "note": null,
      "insight": {
        "aha": "Explanation after an answer often explains a commitment; reasoning before an answer can still change it.",
        "tryThis": "Put scratch work, constraints, and uncertainty checks before the final answer field.",
        "watchFor": [
          "Post-hoc explanations that never revise the answer",
          "A final answer that appears before evidence is considered",
          "Reasoning sections that only paraphrase the conclusion"
        ]
      },
      "extended": [
        "Autoregressive models can only condition on what they have already written. If the answer comes first, the explanation is generated to fit a token that is already locked in. It is rationalization, not reasoning.",
        "Flip the order and the reasoning tokens become real scratch space the final answer can lean on. This is the entire mechanism behind chain-of-thought, and it is why 'answer, then explain' quietly underperforms."
      ],
      "url": "https://tips.platphormnews.com/entries/think-out-loud"
    },
    {
      "id": "attention-viz",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "BertViz for watching attention move",
      "body": "An open-source visualizer that shows which tokens each attention head is looking at, layer by layer. You start to notice heads that only track quotation marks, or ones that follow subject-verb agreement across a whole paragraph.",
      "tag": "tooling",
      "date": "2025 · 10 · 19",
      "publishedAt": "2025-10-19",
      "note": "Most heads are boring. The interesting 5% are worth the dig.",
      "insight": {
        "aha": "Attention is not the whole mind, but it is a useful map of what information is being routed where.",
        "tryThis": "Inspect heads for repeated roles: bracket matching, quote tracking, subject agreement, or copied labels.",
        "watchFor": [
          "Pretty attention maps with no behavioral test",
          "One dramatic head treated as the whole explanation",
          "Patterns that disappear after small prompt perturbations"
        ],
        "labId": "attention-routing"
      },
      "extended": [
        "BertViz draws the attention pattern as lines connecting tokens, split by head and layer. It runs in a notebook in a couple of lines and works on most Hugging Face transformer models.",
        "The value is not the pretty picture, it is the habit of looking. Once you have seen a head that exclusively tracks matching brackets, you stop thinking of the model as a black box and start thinking of it as a stack of small, legible mechanisms."
      ],
      "url": "https://tips.platphormnews.com/entries/attention-viz"
    },
    {
      "id": "negative-space",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Tell it what NOT to do, sparingly",
      "body": "Negative instructions are weak anchors. 'Don't mention X' often makes X more likely because you just put X in the context. Prefer describing the thing you DO want. Reserve negatives for hard safety rails, not style.",
      "tag": "prompting",
      "date": "2025 · 10 · 11",
      "publishedAt": "2025-10-11",
      "note": null,
      "insight": {
        "aha": "Negation still puts the forbidden idea into context. Attention does not forget because grammar says not to.",
        "tryThis": "Rewrite prohibitions as the positive shape of the output you want before adding hard safety rails.",
        "watchFor": [
          "Forbidden words repeated in the response",
          "Style instructions expressed mostly as negatives",
          "A model fixating on the thing you tried to suppress"
        ]
      },
      "extended": [
        "Putting a word in the prompt raises its activation, even when the word is wrapped in 'do not'. The model does not have a clean negation operator the way code does; it has attention, and attention does not know the difference between mention and command.",
        "Rewrite prohibitions as positive descriptions of the target. Instead of 'do not be formal', say 'write like you are texting a friend'. Save the hard negatives for the few rails you cannot express any other way."
      ],
      "url": "https://tips.platphormnews.com/entries/negative-space"
    },
    {
      "id": "feature-probing",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Probe for a concept with a linear classifier",
      "body": "Freeze the model, grab the hidden activations for a pile of examples, and train a tiny linear probe to predict some property (is this text about money? is it past tense?). If a simple line separates them, the concept is already represented in there, plain as day.",
      "tag": "interpretability",
      "date": "2025 · 09 · 30",
      "publishedAt": "2025-09-30",
      "note": "Cheap, fast, and weirdly revealing.",
      "insight": {
        "aha": "If a tiny linear classifier can read a concept from hidden states, the model has already organized that signal.",
        "tryThis": "Probe one concept across layers and look for where accuracy first rises above a simple baseline.",
        "watchFor": [
          "High probe accuracy mistaken for causal importance",
          "Labels that leak through surface wording",
          "Layer sweeps without a held-out validation split"
        ]
      },
      "extended": [
        "The setup is small: collect hidden states from a chosen layer for a labeled dataset, then fit logistic regression on top. High accuracy means the concept is linearly available at that layer.",
        "Sweep the probe across layers and you can watch where a concept first becomes readable. Abstract properties tend to sharpen in the middle layers, which is a clue about where the model is doing the relevant work."
      ],
      "url": "https://tips.platphormnews.com/entries/feature-probing"
    },
    {
      "id": "temperature",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Temperature is a creativity dial, not a quality dial",
      "body": "Turning it up doesn't make answers smarter, it makes them less predictable. For extraction, classification, and anything with a right answer, keep it near zero. For brainstorming, let it wander. People mix these up constantly.",
      "tag": "prompting",
      "date": "2025 · 09 · 22",
      "publishedAt": "2025-09-22",
      "note": null,
      "insight": {
        "aha": "Temperature changes variance, not intelligence. It widens the lottery; it does not improve the tickets.",
        "tryThis": "Set temperature near zero for extraction and scoring, then raise it only when variety is the product.",
        "watchFor": [
          "Creative settings used for factual extraction",
          "One sampled answer treated as a stable result",
          "Quality claims that ignore variance between runs"
        ],
        "labId": "temperature"
      },
      "extended": [
        "Temperature reshapes the probability distribution before sampling. Low temperature sharpens it toward the most likely token; high temperature flattens it so unlikely tokens get a real chance.",
        "So the dial controls variance, not intelligence. If a task has a correct answer, variance is your enemy and you want it near zero. If you want range and surprise, turn it up and sample several times."
      ],
      "url": "https://tips.platphormnews.com/entries/temperature"
    },
    {
      "id": "sae",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Sparse autoencoders to untangle neurons",
      "body": "Individual neurons are polysemantic, one neuron fires for 'the Golden Gate Bridge' and also 'feeling trapped' and also semicolons. Train a sparse autoencoder on the activations and you pull those mixed signals apart into cleaner, single-meaning features.",
      "tag": "interpretability",
      "date": "2025 · 09 · 14",
      "publishedAt": "2025-09-14",
      "note": "This is roughly how the 'Golden Gate Claude' demo worked.",
      "insight": {
        "aha": "Sparse features give you named-ish knobs because they separate mixed neuron behavior into cleaner directions.",
        "tryThis": "Treat an SAE feature as a hypothesis, then test whether steering it changes the behavior you care about.",
        "watchFor": [
          "Human-readable labels that overfit a few examples",
          "Feature steering without downstream behavior checks",
          "Polysemantic residue hiding inside a cleaner-looking feature"
        ]
      },
      "extended": [
        "The trick is over-completeness plus sparsity. You map activations into a much wider space but force only a few of those dimensions to be active at once. The pressure pushes tangled concepts apart into separate, more interpretable features.",
        "Once you have the features you can do surgery: amplify one and watch the model fixate on a bridge, suppress another and watch a behavior fade. It is the closest thing we have to named knobs inside the network."
      ],
      "url": "https://tips.platphormnews.com/entries/sae"
    },
    {
      "id": "token-counter",
      "kind": "tool",
      "kindLabel": "Tool",
      "title": "Keep a tokenizer open in a tab",
      "body": "Half of weird model behavior is a tokenization story. ' apple' and 'apple' are different tokens. Numbers split in unintuitive ways. Pasting your prompt into a tokenizer viewer takes ten seconds and explains a surprising number of bugs.",
      "tag": "tooling",
      "date": "2025 · 09 · 03",
      "publishedAt": "2025-09-03",
      "note": null,
      "insight": {
        "aha": "The model never sees your characters. It sees chunks, spaces, merges, and weird number splits.",
        "tryThis": "Paste the exact prompt, including spaces and separators, into a tokenizer before debugging prompt behavior.",
        "watchFor": [
          "Leading spaces changing label tokens",
          "Numbers split into surprising chunks",
          "Few-shot examples with inconsistent separators"
        ]
      },
      "extended": [
        "Leading spaces, casing, and digit grouping all change how text is split, and the model only ever sees the tokens, never your characters. A trailing space can silently sabotage a few-shot format.",
        "When something is off and you cannot explain it, paste the exact string into a tokenizer view before you theorize. The answer is in there more often than you would expect."
      ],
      "url": "https://tips.platphormnews.com/entries/token-counter"
    },
    {
      "id": "self-consistency",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Sample many, keep the majority",
      "body": "For reasoning tasks, generate the same answer five or ten times at moderate temperature and take the most common result. A single greedy answer is fragile; the consensus across samples is far more reliable. Slow, but it works.",
      "tag": "reliability",
      "date": "2025 · 08 · 25",
      "publishedAt": "2025-08-25",
      "note": null,
      "insight": {
        "aha": "Wrong reasoning paths tend to scatter; correct reasoning paths often converge.",
        "tryThis": "Sample several answers, normalize the final claim, and inspect disagreement before majority voting.",
        "watchFor": [
          "Repeated wording counted as independent evidence",
          "Voting over outputs that all share the same missing assumption",
          "Compute spent on low-value questions"
        ]
      },
      "extended": [
        "Different samples take different reasoning paths but tend to converge on the same correct answer, while the wrong answers scatter. Voting over the final answers turns that asymmetry into accuracy.",
        "It costs you N times the compute, so reserve it for the questions that matter. A useful middle ground is to escalate to self-consistency only when the first answer looks low-confidence."
      ],
      "url": "https://tips.platphormnews.com/entries/self-consistency"
    },
    {
      "id": "context-rot",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Mind the middle of long contexts",
      "body": "Models attend strongly to the beginning and end of a long prompt and get foggy in the middle. Put the instructions and the most important facts at the edges. If something keeps getting ignored, it's probably buried in the soft center.",
      "tag": "prompting",
      "date": "2025 · 08 · 12",
      "publishedAt": "2025-08-12",
      "note": "Sometimes called 'lost in the middle'.",
      "insight": {
        "aha": "A fact can be present and still practically invisible if it sits in the soft middle of a long prompt.",
        "tryThis": "Move critical constraints to the opening contract and repeat the single highest-risk fact at the end.",
        "watchFor": [
          "Middle facts ignored while opening and closing instructions are followed",
          "Retrieved context pasted without ranking",
          "Important constraints surrounded by low-value filler"
        ],
        "labId": "context-position"
      },
      "extended": [
        "Retrieval accuracy as a function of position tends to be U-shaped: strong at the start, strong at the end, sagging in the middle. A fact you need can be technically present and still effectively invisible.",
        "Design around it. Lead with the instruction, restate the critical constraint at the very end, and keep the soft middle for material you can afford to lose."
      ],
      "url": "https://tips.platphormnews.com/entries/context-rot"
    },
    {
      "id": "activation-patching",
      "kind": "method",
      "kindLabel": "Method",
      "title": "Activation patching to find the cause",
      "body": "Run the model twice, once on a clean prompt and once on a corrupted one, then copy a single activation from one run into the other. If the output flips, you just found a component that carries the behavior. It's causal, not just correlational.",
      "tag": "interpretability",
      "date": "2025 · 07 · 30",
      "publishedAt": "2025-07-30",
      "note": "The closest thing in this field to a controlled experiment.",
      "insight": {
        "aha": "Correlation says a signal is present. Patching asks whether changing that signal changes the outcome.",
        "tryThis": "Patch one layer-position activation from a clean run into a corrupted run and track whether the answer flips.",
        "watchFor": [
          "Large sweeps without a clean causal hypothesis",
          "Output flips caused by formatting rather than the target behavior",
          "A single patch interpreted without replication"
        ]
      },
      "extended": [
        "Probes tell you what is represented. Patching tells you what matters. By swapping one activation and watching the effect, you move from 'this information is present' to 'this component causes the behavior'.",
        "Sweep the patch across layers and positions to localize the circuit. The spots where patching flips the answer are the load-bearing ones; everything else is along for the ride."
      ],
      "url": "https://tips.platphormnews.com/entries/activation-patching"
    },
    {
      "id": "few-shot-format",
      "kind": "tip",
      "kindLabel": "Tip",
      "title": "Your examples frame format louder than content",
      "body": "In few-shot prompts the model copies the shape of your examples first: the punctuation, the casing, the length, the label words. Get the format dead consistent and the task often solves itself. Sloppy examples frame sloppiness.",
      "tag": "prompting",
      "date": "2025 · 07 · 18",
      "publishedAt": "2025-07-18",
      "note": null,
      "insight": {
        "aha": "Few-shot examples frame surface form first. The model copies the pattern before it understands your intention.",
        "tryThis": "Make labels, punctuation, casing, separators, and example length boringly consistent.",
        "watchFor": [
          "One example with a different label shape",
          "Multi-token labels competing with single-token labels",
          "Examples that demonstrate style drift instead of the task"
        ]
      },
      "extended": [
        "Few-shot learning is pattern continuation. The model is extremely sensitive to surface form, sometimes more than to the actual reasoning you intended to demonstrate.",
        "Make every example identical in structure, pick label words that are single clean tokens, and keep lengths similar. The more rigid the template, the more reliably the model fills in the next blank."
      ],
      "url": "https://tips.platphormnews.com/entries/few-shot-format"
    },
    {
      "id": "logit-lens",
      "kind": "method",
      "kindLabel": "Method",
      "title": "The logit lens: decode the middle layers",
      "body": "Take the hidden state from an intermediate layer and run it through the model's output head early. You get the model's 'best guess so far' at that depth. Watching the prediction sharpen layer by layer is like a time-lapse of a thought forming.",
      "tag": "interpretability",
      "date": "2025 · 07 · 05",
      "publishedAt": "2025-07-05",
      "note": null,
      "insight": {
        "aha": "The answer often appears before the wording is polished. Middle layers can show the thought taking shape.",
        "tryThis": "Decode intermediate layers and watch when the target answer first becomes linearly readable.",
        "watchFor": [
          "Early guesses treated as final causal proof",
          "Layer readouts that shift after prompt paraphrases",
          "Ignoring later layers that suppress unsafe or irrelevant continuations"
        ]
      },
      "extended": [
        "The output projection is just a linear map, so nothing stops you from applying it to an earlier layer. The result is a rough readout of what the model would say if it had to stop thinking right now.",
        "Often the correct answer appears in the middle layers and the later layers spend their budget refining phrasing and suppressing alternatives. Seeing that handoff demystifies a lot of model behavior."
      ],
      "url": "https://tips.platphormnews.com/entries/logit-lens"
    }
  ]
}