Part I — Software That Explains Itself
FlowBook begins with a practical question: why does critical software become hardest to understand at the moment people most need to understand it?
Part I follows that question from a costly incident into Flow-Like’s core design. It explains why software structure, execution paths, permissions, and failures should remain visible beyond the original author’s editor. It then maps the platform vocabulary—Apps, Flows, Boards, Events, data, and execution—before turning the argument into a small program you can inspect in two honest views.
By the end of this part, you will be able to:
- explain the operational problem Flow-Like and FlowScript are designed to address;
- evaluate the trade between unconstrained code and typed, governed building blocks;
- distinguish an App, Flow, Board, Event, and authoring surface; and
- build a deterministic incident-triage Flow, read its node graph, and edit its FlowScript.
The chapters form one sequence. The incident establishes the stakes, the manifesto states the constraints, the platform model names the moving pieces, and the tutorial proves that the same workflow can remain readable as source, graph, and runtime evidence.
Part I · Open edition · 2026
Chapters in this part
- 01
The 3 A.M. Call
A major incident reveals why Flow-Like was built for visible software structure, operational evidence, and domain knowledge that survives its author.
- 02
The Manifesto: Constrained Freedom
Explore Flow-Like’s principles for typed building blocks, legible workflows, safe extension, governed execution, and freedom without hidden liabilities.
- 03
One Platform, One Flow Model
Understand how Flow-Like Apps, Flows, Boards, Events, data, permissions, authoring surfaces, and local or remote execution fit into one model.
- 04
First Flow: Incident Triage in Two Views
Build a deterministic incident triage Flow, inspect its node graph, edit it in FlowScript and Studio, trace failures, and save a tested version.