Why A Living Book
CPUX is not only a software architecture. It is an attempt to make perception, intention, and execution visible enough to become part of computation.
That kind of work cannot be finished as a static manual too early.
A conventional framework guide usually begins after the framework has already stabilised. It explains APIs, configuration, lifecycle hooks, extension points, and examples. CPUX needs that too, but it also needs something before that: a place where the concepts, demonstrations, human ground, and platform contracts mature together.
This is the role of the living book.
The Work Is Still Forming
The current CPUX model already has concrete demonstrations in ReactJS and Android GridLookout. It also has architectural notes for Signals, Pulses, Objects, Design Nodes, Intention Containers, Fields, FieldBoards, direct IC results, and visitor execution.
But the deeper importance of CPUX is not limited to these mechanisms.
The deeper question is:
how can computation preserve the human loop of perception, intention, action, and stabilisation?
That question touches software architecture, UI design, distributed systems, AI, cognition, social responsibility, and the practical craft of building applications.
A living book allows those layers to develop without forcing them into a premature final shape.
What Should Stay Stable
Even as the book grows, some foundations should remain stable:
- human perception is the starting point of meaningful interaction
- intention should be represented explicitly
- computation should not hide its path of understanding
- UI should reflect human action rather than silently transform it
- Design Nodes should be independently executable
- Objects should reflect and persist rather than compute secretly
- CPUX Fields should make evolving situational state visible
- GridLookout should keep the rendering platform separate from the CPUX model
These are not merely implementation choices. They are the ethical and architectural spine of the work.
What Should Remain Open
Other parts should remain open and experimental:
- how far Stabilising Intelligence can be formalised
- how AI systems should participate as Design Nodes
- how much contextual grounding every Signal needs
- how native GridLookout should appear on iOS, Flutter, desktop, and embedded systems
- how CPUX should scale across teams, devices, and distributed runtime environments
- how intention-representable design can influence social software and public systems
The living book should let these questions breathe while still giving developers something they can build.
The Reader's Path
The book should support several kinds of reader:
- a developer who wants to build a Perceptive App
- a UI engineer who wants to understand GridLookout
- an Android or React developer studying the current demonstrations
- an iOS or Flutter developer preparing for future native GridLookout work
- an AI engineer thinking about context and human-centred reasoning
- a researcher interested in situational reality and Stabilising Intelligence
Each reader should be able to enter the book through a practical doorway, then discover the deeper foundation behind it.
The Living Test
The book matures only when two things stay connected:
philosophical claim <-> executable demonstration
If a chapter says that human perception should remain central, there should eventually be a UI example showing how direct IC result preserves that loop.
If a chapter says that intention should be explicit, there should eventually be a Signal example showing the intention carried through execution.
If a chapter says that CPUX is cross-platform, there should eventually be GridLookout implementations proving that the same model can appear through different native surfaces.
This is the standard for the living book.