Entry I / Public Build Log · Selected milestones only

Building the question into something testable.

This page shows selected public-safe progress: what changed, why it matters, and what evidence exists.

Protected implementation stays privatePublic claims remain bounded
HOW THE BUILD IS READ

Build it. Test it. Show the evidence.

Selected public-safe work, described only where evidence can support it.

BUILD IT

Turn the research question into functioning software or a testable scenario.

TEST IT

Challenge assumptions, find failures and correct what does not hold up.

SHOW THE EVIDENCE

Publish only the part that can be supported without exposing protected implementation.

AcceptanceEvidence checked first

Public log updated 4 November 2026. The record below describes the website experience and selected dated progress.

04 NOV 2026 · PUBLIC WEBSITE RECORD

What does this website show?

The Consequence Room explores a changed instruction through three fictional outcomes. The research pages and dated progress entries provide wider context. This story does not demonstrate a deployed Entry I capability.

THE EXPERIENCE

Explore the room

Follow the fictional flight request and choose a possible response.

THE CONTEXT

Read the wider context

Read the public research position and selected dated progress records.

BEFORE WE CALL IT DONE

Checked before accepted

Work is only treated as complete after testing, correction and review.

See recent progress
FILTER What would you like to look at?

Showing all published entries.

  1. Public website

    The Consequence Room has its own page.

    The fictional experience follows a request for flight options, a changed instruction and three possible outcomes. It illustrates a research question without proving how a real agent would behave.

    Enter the room →
  2. Public website / clarity

    The public site is easier to follow on desktop and phone.

    The interactive story, Case Lab, Build page and Work page were tightened so visitors see less at once, read larger text, and get a clearer next action.

    What can we say publicly? The public explanation has been improved without publishing protected implementation details or changing the underlying research claims.
  3. Public explanation / evidence framing

    The website now shows the work, not just the question.

    The homepage now separates software answering from software acting, uses a human-readable agent example, and makes implementation, testing, evidence and independent checking easier to see.

    What can we say publicly? Visitors can now see that Entry I is not claiming ownership of the broad question. The reason to keep watching is the work being built, tested, corrected and checked over time.
  4. Public explanation

    Visitors can now try the public question for themselves.

    A conceptual story lets a visitor follow an action through changed circumstances, make a choice, and see the consequence.

    What can we say publicly? The research question became easier to experience without publishing Entry I’s protected mechanism, architecture or enforcement logic.
  5. Public research / website

    Research, Signals and submissions open to the public.

    Research Notes, public Signals and a controlled submission path became part of the public Entry I site.

    What can we say publicly? Visitors can read a public research note, inspect selected outside developments, follow Entry I, and send relevant material for review.
Show older public milestones (5)
  1. Public language

    The first-contact website is simplified around one concern.

    The public explanation was tightened so a first-time visitor can understand the concern without seeing Entry I’s internal architecture or protected mechanisms.

    What can we say publicly? The site became clearer about AI systems going beyond what a person intended, while keeping development status and illustration boundaries visible.
  2. Correction & review

    A problem was found, fixed, retested and checked again.

    A previously identified implementation issue was corrected, retested and independently reviewed before the work was treated as complete.

    What can we say publicly? Entry I can state that a corrective milestone was accepted after re-review. The underlying defect, implementation and exact evidence remain private.
  3. Independent review

    A development milestone passes independent review.

    A selected milestone moved through implementation, testing and independent review within its defined scope.

    What can we say publicly? Entry I can record independent acceptance of a bounded development milestone without publishing internal implementation, test structure or workstream names.
  4. Technical milestone

    Another tested milestone is accepted.

    A tested development milestone moved through another controlled review cycle and was accepted within its defined scope.

    What can we say publicly? The milestone is acknowledged without publishing internal state names, transition rules, test counts or case identifiers.
  5. Active development

    Entry I starts turning research into implemented and tested work.

    The project began converting its governing questions into bounded technical work, reviewable evidence and controlled public explanation.

    What can we say publicly? The public record starts here. Earlier internal research remains internal unless there is a specific reason to publish it safely.