System

The physical Project Quantum Leap artifact is a small embedded system built to answer a deceptively simple question:

What state should the machine be in right now?

Everything else follows from that answer.

The clock establishes the current time. The state engine interprets that time. The display communicates it numerically. Lighting communicates it visually. Controls allow deliberate interaction. Persistent storage allows the machine to remember what it needs to remember.

The hardware exists to make the state tangible.

01 // Controller

The current design is centered on an ESP32-class microcontroller.

The controller is responsible for:

• reading authoritative time from the real-time clock
• determining the current system state
• calculating countdown values
• calculating Time Reclaimed
• driving the numerical display
• controlling programmable lighting
• processing physical input
• handling optional infrared interaction
• maintaining persistent local state
• providing diagnostic behavior when necessary

The ESP32 also leaves room for future communication between the physical artifact and its digital twin.

That capability should remain optional.

The machine should continue performing its core function even without a network connection.

02 // Timekeeping

Time is the primary input to Project Quantum Leap.

A DS3231 real-time clock provides persistent local timekeeping independently of the controller’s runtime clock.

The RTC allows the artifact to recover from:

• normal shutdown
• accidental restart
• temporary loss of primary power
• firmware updates
• extended periods without network access

The system should not require an internet connection merely to know whether Reclamation Day has arrived.

The RTC therefore acts as the physical machine’s authoritative operational clock.

Network time, if eventually implemented, should be treated as a synchronization mechanism rather than as the machine’s only source of truth.

03 // State Engine

Raw time does not directly determine appearance.

It determines state.

The physical firmware should follow the same conceptual model used by the digital twin:

JOURNEY STATE
The durable milestone currently reached.

DISPLAY STATE
The state responsible for current status, presentation, and lighting behavior.

The physical artifact does not need to reproduce every content function of the website. Unlock State, Field Notes, Mission Events, and archival navigation belong primarily to the digital twin.

What the artifact must understand is the shared timeline.

That includes:

• Final Year
• Retirement Window
• Approaching Totality
• Totality
• Returning Light
• Twenty Years
• Reclamation Day
• the persistent future state

The same date should mean the same thing on both machines.

04 // Display

The numerical display is the artifact’s primary expression of time.

Before Reclamation Day, it presents a countdown.

The principal vocabulary is:

DAYS / HRS / MIN / SEC

The target can change as meaningful milestones are reached, allowing the instrument to continue moving toward the next objective rather than remaining frozen after intermediate dates.

On Reclamation Day, the display reaches zero.

000 DAYS / 00 HRS / 00 MIN / 00 SEC

It remains at zero for the entire calendar day.

Beginning 02 NOV 2027, the instrument changes mode.

TIME RECLAIMED

The persistent future display uses:

YEARS / DAYS / HRS / MIN

Years and days should be calculated using calendar-aware logic rather than treating a year as an arbitrary fixed number of days.

The display is not merely output.

It is the clearest statement of what the machine currently believes time means.

05 // Lighting

Addressable RGB lighting provides the artifact’s visual state.

Lighting should be driven by semantic system states rather than by arbitrary animations.

The firmware should understand concepts such as:

QUANTUM
Cool cyan and blue.

FIRST LIGHT
Cool light with the first introduction of warmth.

APPROACHING TOTALITY
Reduced saturation and restrained illumination.

TOTALITY
Near-dark presentation with minimal warm or neutral highlights.

RETURNING LIGHT
Warm light gradually reasserting itself.

SUNRISE
Orange and increasingly warm illumination.

DAYLIGHT
The brightest and warmest persistent visual language.

Transitions may eventually include fades, pulses, or other motion, but animation should support meaning rather than become the meaning.

The machine should remain understandable while standing still.

06 // Physical Input

The current design includes a primary illuminated physical control.

Its final behavior remains part of the build process.

Potential functions include:

• waking or changing display information
• cycling diagnostic information
• acknowledging a system condition
• entering a local information mode
• initiating a deliberate interaction or Easter egg

The control should not be assigned functionality merely because the hardware is available.

Its behavior should become clear through use.

The illuminated portion of the control should also be electrically isolated from direct microcontroller drive when its voltage or current requirements exceed what a GPIO pin can safely provide.

A transistor or MOSFET driver may therefore be required.

07 // Infrared

Optional infrared transmission and reception provide another possible interaction channel.

Infrared should be treated as data, not simply as the presence or absence of light.

The receiver should decode meaningful signals before the firmware responds.

This leaves room for intentional interaction with compatible remotes, diagnostic tools, or future project-specific commands.

The infrared subsystem is optional.

Project Quantum Leap must remain fully functional without it.

08 // Persistence

The artifact needs to recover gracefully after interruption.

Persistent storage should retain only information that actually needs to survive a restart.

Potential persistent data includes:

• configuration
• calibration values
• user-selectable preferences
• interaction state
• diagnostic information
• synchronization metadata

The current phase itself generally does not need to be permanently stored as truth.

It can be derived again from the clock and authoritative timeline.

This is an important design principle:

Store what cannot be derived. Derive what can.

That reduces the chance that saved state and actual time disagree.

09 // Power and Electrical Interfaces

The controller, display, lighting, RTC, illuminated control, and optional infrared components do not necessarily share identical electrical requirements.

Power distribution must therefore be treated as part of the system design rather than as an afterthought.

Known considerations include:

• sufficient current capacity for addressable lighting
• appropriate local decoupling
• a shared electrical reference where required
• protection of microcontroller GPIO
• voltage compatibility between 3.3 V logic and 5 V peripherals
• display logic-level compatibility
• suitable switching for illuminated controls
• stable power during lighting transitions

Some WS2812-class addressable LEDs may operate reliably from a 3.3 V data signal while powered at 5 V, but that behavior should not be assumed as a design guarantee.

A proper logic-level shifter may be appropriate.

The same compatibility question applies to any 5 V display electronics expecting logic HIGH levels above what the ESP32 reliably provides.

These interfaces should be tested before the enclosure makes them difficult to change.

10 // GPIO and Hardware Safety

ESP32 pins are not interchangeable simply because they can be referenced as GPIO.

Bootstrapping pins, input-only pins, peripheral assignments, and startup behavior all matter.

GPIO assignments should therefore be finalized only after the complete hardware map is reviewed.

In particular, pins involved in ESP32 bootstrapping should not be casually assigned to external hardware capable of forcing an unwanted level during startup.

The final pin map belongs in the implementation specification once the hardware configuration is settled.

11 // Failure Behavior

A meaningful artifact should fail gracefully.

If optional functionality disappears, the core instrument should remain useful.

A reasonable hierarchy is:

TIME FIRST

STATE SECOND

DISPLAY THIRD

LIGHT FOURTH

INTERACTION FIFTH

If network connectivity fails, the clock should continue.

If synchronization fails, the local timeline should continue.

If optional infrared hardware fails, the countdown should continue.

If decorative lighting fails, the numerical instrument should still communicate time.

The closer a component is to the central purpose of Project Quantum Leap, the less dependent it should be on optional systems.

12 // Current Engineering Status

The system architecture is defined more clearly than the final electrical implementation.

Current design direction:

Subsystem	Direction	Status
Controller	ESP32-class MCU	Planned
Timekeeping	DS3231 RTC	Planned
Numerical Display	Persistent countdown / Time Reclaimed	Planned
Lighting	Addressable RGB	Planned
Physical Input	Illuminated primary control	Planned
Infrared	Transmit / receive	Optional
Persistence	Local nonvolatile storage	Planned
Networking	Digital twin synchronization	Future capability
Power	Regulated shared system supply	Engineering required

The physical build will determine the exact display hardware, power topology, GPIO map, level shifting, enclosure layout, connectors, and serviceability strategy.

Those details can change.

The governing principle should not:

The hardware serves the state. The state serves the story.