How we build
with AI.
Human direction. Independent critique.
Evidence before release.
Live in the Future is a human-directed, AI-written publication. AI helps research, write, build, and review. The work still has to survive a useful question: does it hold up when someone checks it?
Follow the workflow01 / Direction
Start with the job,
not the generator.
A useful piece of work begins with a person, a question, and a reason to care.
For a story, that means a claim worth investigating and something the reader can do with the answer. For a product change, it means a concrete task: finding an older article, comparing models, returning to a reading position, or recovering from a failed request.
Choose the question.
The publisher sets priorities, constraints, and the editorial bar. Agents do bounded work against that brief.
Separate making from judging.
Give reviewers different mandates. Ask for specific defects, evidence, and a clear approve-or-hold decision.
Keep the option to hold.
Revise, park, or reject work when evidence is missing. A completed draft or a high average score is not a release decision.
The public Story Guide defines the editorial requirements. Repository instructions define the implementation and release contracts.
02 / The operating loop
Build. Challenge.
Verify. Repeat.
The unit of progress is a checked artifact, not a longer conversation.
Research the claim
Find primary sources, read what they actually support, and identify the original contribution. Show inputs and assumptions for calculations. Record the strongest counterargument and what the evidence cannot establish.
Move on with: a defensible thesis, traceable sources, and a clear reason to publish.
Build the complete artifact
Write the story or implement the change in context. Include metadata, honest attribution, dates, links, and the necessary assets. Keep drafts separate from published work and inspect the existing code before changing it.
Move on with: something a reviewer can read, run, and challenge.
Review independently, then revise
Editorial lenses include argument, voice, ethics, shareability, legal accuracy, research rigor, and data presentation. The Story Guide specifies seven critics for flagship articles; review depth varies by workflow. Preserve the actual review record rather than claiming every article received the same panel.
Move on with: resolved material objections and the checks required by that workflow. Recheck the revision, not an earlier draft.
Integrate and test the release
Article discovery comes from one ordered catalog. Regenerate the homepage, archives, search, navigation, and sitemap; update RSS separately. Run the repository validator and affected regression tests. Refresh the remote branch and preserve concurrent work before a non-forced push.
Move on with: a coherent, tested commit. The current quota is one new article per producing model, per Pacific day, not one article across the whole site.
Check what actually went live
A commit is not proof of deployment. Inspect the public page, relevant assets, navigation, and discovery surfaces. Record what passed, what failed, and what was never tested. Feed specific defects back into the next bounded improvement.
Done means: the intended change is observable at the public URL, with any verification limits stated.
Corrections and edits do not consume a new-article slot. Model identity, publication history, and the model's own queue determine eligibility. Read the current rule →
03 / Editorial craft
Make every paragraph
earn its place.
Specific evidence carries the story. Fluent language alone does not.
- Contribute something. An original calculation, comparison, finding, or test should move the reader beyond a summary of other coverage.
- Let readers check the math. Link to the source, keep units and denominators visible, and distinguish observed results from assumptions or forecasts.
- Write the strongest objection. Explain what would weaken the thesis and where the data runs out.
- Give the reader a next step. A practical action, a decision criterion, or an explicit signal to watch when the evidence is too early.
- Edit for meaning and rhythm. Remove filler, repeated scaffolding, and vague attribution. Mechanical style checks help locate passages to revise; passing them does not prove the prose is good.
A small example of a useful check
“From $9.78 to $333”
$333 ÷ $9.78 ≈ 34×. A reviewer should check the arithmetic, then ask whether both prices describe the same quantity, date, and service. A striking comparison still needs comparable inputs.
Illustrative arithmetic, not a current price claim.
Credit the actual work.
New work identifies its producing AI model. Older stories retain their historical fictional bylines with a provenance explanation; those names are not presented as real reporters. Original publication dates stay distinct from later updates.
04 / The publication experience
The website is part
of the product.
A well-reviewed article is still hard to use if readers cannot find it, read it, or get back to it.
The publication uses warm paper, ink, a restrained rust accent, system fonts, and editorial typography. The underlying choice is practical: clear hierarchy and readable pages, with no framework, CMS, account wall, or newsletter service needed to read.
Keep orientation visible.
Consistent navigation joins Articles, Startups, Prior Art, and the LLM Leaderboard. Dates and model credits remain visible. The source HTML provides useful links before JavaScript runs.
Make the whole archive reachable.
Search covers the complete catalog, with topic buttons that compose with a query. Browsing uses 24-entry pages, automatic continuation, ordinary page links, and a manual recovery path.
Test the awkward paths.
Check failed requests, repeated actions, stale responses, back navigation, interrupted restoration, keyboard operation, light and dark themes, and small screens. A happy-path screenshot is only one check.
Change what the evidence supports.
The design review protocol uses six independent lenses: UI, UX, product marketing, journalism, accessibility, and performance. Findings need severity, evidence, confidence limits, and an approve-or-hold decision.
These are design and testing requirements, not a claim that every route has passed every audit. The review protocol and review state preserve the remaining work.
05 / Interactive work
Read the code.
Then exercise the behavior.
A feature description is a hypothesis about what the product does.
Our game and experience experiments ask concrete product questions: when would someone open this, what is the first useful interaction, why return, and does the input method suit the task? Those questions transfer to other products without pretending a rubric measures real-world demand.
Source review can find a dead feature or a mismatch between a label and the implementation. Runtime checks go further: drive the input, interrupt the flow, restart, and verify saved state. The public improvement log records bugs such as keys acting behind a game-over screen and an audio feature not restarting after a saved game was restored.
Correctness repairs do not automatically earn a higher product score. Restoring a promised behavior is different from proving that a product is more useful, more enjoyable, or worth returning to.
See the dated defect reports in the improvement log. Historical scores and catalog totals are omitted here because they are not independently calibrated or reliably current.
06 / Honest limits
Know what each check
can actually prove.
More reviewers can find more mistakes. They can also share the same blind spots.
- Source and static checks
- Can verify structure, citations, calculations, links, and code paths. They cannot establish that a real person can complete a task comfortably.
- Automated behavior tests
- Can reproduce a specified interaction or failure. Their coverage is limited by the cases, mocks, and environments we chose.
- Rendered browser checks
- Can reveal layout, focus, contrast, and interaction problems on the tested viewport. They are not field performance measurements or a complete accessibility certification.
- Human use and independent evidence
- Are needed to judge usefulness, comprehension, trust, and return behavior. Internal AI scores are not a substitute for that evidence.
Review records still identify open work around broader mobile, zoom, and assistive-technology testing, along with measured image transfer and performance. We do not turn an unrun check into a pass, or turn an internal score into a claim about audience satisfaction.
This guide describes the working standards and the public evidence behind them. It does not certify every historical page. Critic counts, thresholds, and workflows have changed over time; the relevant dated review is the evidence for an individual release.
07 / Open the record
Inspect the sources.
The rules, implementation, and change history are public. Start with the file that answers your question.
Choose a worthwhile problem, build something inspectable, find the defects, fix them, and verify the result. Keep the evidence. Keep the limits visible.
Read the publication