What is it?
Name the product and what it actually does. Avoid unsupported features and vague promises.
THE UNITIQX / SPHYNX OPEN EXPERIENCE MANUAL
EVERYTHING SHOULD
EXPLAIN ITSELF.
One consistent field manual for games, web apps, AI research tools, operating-system guides, hardware comparisons, tutorials, videos and future experiments. If a public artifact cannot explain its purpose and evidence, it is not ready to be presented as complete.
WHAT EVERY VISITOR DESERVES TO KNOW
Nine questions before you begin
Why does it exist?
Explain the problem, creative purpose, or educational outcome in language newcomers understand.
Who can use it?
State target audience, prerequisite skills, supported devices and eligibility limits.
How do I start?
Give a first action, keyboard/touch controls, safe examples, expected input format and direct links.
What is winning?
Give an observable completion target—31/31 missions, a valid result, a tested build, or a correctly classified record.
What if it fails?
Describe blocked moves, timeouts, no-results, offline states, retries and recovery before a visitor is surprised.
Can I think it through?
Show a text scenario, starting state, available actions, likely outcomes and a checkable answer.
Can I understand it visually?
Include authentic screenshot with descriptive alt text, video narration, captions and full transcript.
What has been proven?
Identify actual browser tests, simulations, provider receipts, data policies and what remains unverified.
PLAY WITHOUT PLAYING · THINK WITHOUT TOOLS
How to run a mental simulation
- Read the actual source of the rules. For Matrix Arcade, read the 31 published challenge states.
- Describe what is present. For a maze, identify S, K, walls and E. For an API, identify inputs, outputs, constraints and known errors.
- Choose one legal action. Make the smallest possible claim, e.g. “Move south from the current tile.”
- Predict the next state using the disclosed rule. If the rule is uncertain, say what assumption must be confirmed.
- Compare with the known solver/reference or run a separately authorized test. Label whether the outcome was theoretical, executed, or observed.
- 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.
REPEATABLE PRODUCTION CONTRACT
Publishing checklist for any medium
- Identify canonical product version and safe public source of truth.
- Write plain-language purpose, audience, how-to, goals, feedback, failure and recovery.
- Write independent machine-readable contract and read-only hypothetical scenario.
- Capture actual public product screenshots; label source and avoid private pages.
- Make locally narrated intro/real authorized demo and transcript; label what actually happened.
- Check keyboard, mobile viewport, alt text and readable non-JavaScript content.
- Review privacy, sensitivity, URLs, credentials, rate limits and no-admin boundary.
- Run representative positive and negative QA; record actual proof separately from claims.
- Publish through an explicit static route allowlist with backup/rollback.
- 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.
PRIVACY / ACCESS / RECOVERY
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.