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. The final chapter turns the argument into a small program you can inspect in two authoring 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 view; 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 software needs visible 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, integrations, Events, data, permissions, and execution fit together.
- 04
First Flow: Incident Triage in Two Views
Build a deterministic incident triage Flow, edit its Board through FlowScript and the canvas, inspect failures, and save a tested version.