EVERYTHING SHOULD
EXPLAIN ITSELF.

Nine questions before you begin

How to run a mental simulation

1. Read the actual source of the rules. For Matrix Arcade, read the 31 published challenge states.
2. Describe what is present. For a maze, identify S, K, walls and E. For an API, identify inputs, outputs, constraints and known errors.
3. Choose one legal action. Make the smallest possible claim, e.g. “Move south from the current tile.”
4. Predict the next state using the disclosed rule. If the rule is uncertain, say what assumption must be confirmed.
5. Compare with the known solver/reference or run a separately authorized test. Label whether the outcome was theoretical, executed, or observed.
6. Record what the choice teaches. That may be a route, a debugging hypothesis, a source-reliability judgment or a design trade-off.

Example read-only AI line: “I would rotate tile 5 clockwise once, predict the connected openings and check whether tile 6 points back to it. This is rules-based hypothetical play, not an executed browser action.”

Never substitute an invented tool receipt, screenshot or simulated model identity. When an AI cannot operate the browser, it can still reason and teach correctly from public state descriptions.

Publishing checklist for any medium

1. Identify canonical product version and safe public source of truth.
2. Write plain-language purpose, audience, how-to, goals, feedback, failure and recovery.
3. Write independent machine-readable contract and read-only hypothetical scenario.
4. Capture actual public product screenshots; label source and avoid private pages.
5. Make locally narrated intro/real authorized demo and transcript; label what actually happened.
6. Check keyboard, mobile viewport, alt text and readable non-JavaScript content.
7. Review privacy, sensitivity, URLs, credentials, rate limits and no-admin boundary.
8. Run representative positive and negative QA; record actual proof separately from claims.
9. Publish through an explicit static route allowlist with backup/rollback.
10. Monitor availability and review each product upon version changes.

Universal evidence labels

observed_public_route

An HTTPS/HTTP response from a specific approved public endpoint at a recorded time

automated_browser_receipt

A browser actually visited and acted on a page; not a human experience or provider inference run

unit_rule_simulation

Deterministic state transitions computed from published local code

hypothetical_thought_exercise

An illustrative plan or decision without any software execution

photo_or_screenshot

Must state whether actual product capture, test environment, stock imagery or generated illustration

narrated_screenshot_tour

A locally rendered audio/video introduction from screenshots, NOT a real click-by-click workflow demonstration

independent_model_run

Needs actual connector response, model identity, tool receipt, permitted route and time

verified_human_test

Requires real participant and observed or consented feedback

unknown

Never silently upgrade unknown or historical assertions to verified.

Public content is not public administration

All readers may inspect approved public documents. They do not receive owner login, provider tokens, private workbench access, a cloud shell, or unrestricted remote crawling. Advanced capabilities require separate isolated public workers, limits and real acceptance evidence.

A useful experience must remain intelligible even if an AI provider, media player, physical controller or JavaScript renderer is unavailable. Every important concept should have a text equivalent and a working entry point.