Formalization · v0.2
Instrumenting synchronization
Tools for applying and evaluating the foundations where they are relevant. An interpretation in progress, not the definition of SyncThinkDesign.
What this page is
The foundations say what SyncThinkDesign proposes. This page gathers ways of putting it into practice and testing it. It contains mechanisms (M), tools that can be used when they help; hypotheses (H), claims about the effects of the proposal that may turn out false; and open questions (Q).
A model of inputs and outputs
To study how the processes influence each other, it helps to describe what each needs in order to start and what it produces. The table is one possible model, useful above all in technology projects; other areas may need a different one.
| Process | Minimum input | Produces | Consumed by |
|---|---|---|---|
| Capture | A question or an available source. | Observations with source and date. | Ideate and Optimize. |
| Ideate | At least one observation or a declared assumption. | Ideas, hypotheses, decisions, specifications. | Execute and Capture. |
| Execute | An idea or hypothesis worth bringing into reality. | Working parts of the system; constraints discovered. | Optimize and Ideate. |
| Optimize | Something in use and some signal about how it works. | Improvements, judgments about what worked, new questions. | Execute, Ideate and Capture. |
Synchronization mechanisms
Principle F2 can be met in many ways. These are some mechanisms we have found useful or that came out of AAA3. They can be combined, adapted or ignored.
Explicit shared state. When it helps to make synchronization traceable, processes can read from and write to a common record of observations, ideas, hypotheses and decisions, with author and date. It can be a text file, a database or the very document that describes the system.
Minimum input. A process can start as soon as the information it needs exists, without waiting for another to declare itself done. The dependency between processes is one of information, not of calendar.
Outputs with a recipient. An output that says which process will use it is more likely to influence it. An artifact nobody will read synchronizes nothing.
A refutation criterion, where it fits. If an idea is brought into reality to check something, it helps to say in advance which result would contradict it. Not every creative or organizational decision admits this form, and it should not be forced.
Event-driven propagation. Information can flow whenever something relevant happens —an observation, a decision, a change in the system— instead of waiting for a periodic meeting. A weekly review is an implementation option, not a requirement.
Local stability. An approved part of the system can be protected so that it does not change without an explicit decision, while the other parts keep evolving. Protecting a decision is not stopping the system's evolution. The concrete form of this mechanism comes from AAA3's pin (I6).
Deliberate separation. Sometimes processes should not overlap: when an action is irreversible or expensive to undo, when one stage is a formal requirement for the next, or when there is still no way to obtain signals. Deciding when to separate is part of synchronizing well.
Week 8. The portal is in use and keeps changing with what is observed. The false assumption cost one week of work, not three. Ideate → Execute: adjustment.
- False assumption detected in
- Week 3
- Work done on the false assumption
- 1 process-week
A scenario built to explain one mechanism. The numbers come from the scenario, not from a measurement.
Every week, as text
- Capture interviews users. At the same time, Ideate notes the assumptions the idea depends on. One of them: «the ERP has per-customer prices».
- Execute builds a small test: read three customers' prices from the ERP. In parallel the portal skeleton gets started, and it too assumes the assumption holds.
- Optimize looks at the result: there are no per-customer prices. The finding reaches every process.
- Ideate reformulates: prices will come from the discount list kept by the sales team. Capture gets hold of that list. Execute stops working on the old assumption. The portal is no longer the one that was planned.
- Execute connects the new price source. Optimize looks at the first test order.
- Optimize asks Capture to observe real use with two distributors: why does one of them not order again?
- All four processes are active. That has a real coordination cost, and in a very small team it might not pay off (hypothesis H7).
- The portal is in use and keeps changing with what is observed. The false assumption cost one week of work, not three.
When to separate processes
Mechanism M7 rests on an idea from Donald Reinertsen: in product development, the cost of delay is usually invisible and larger than the cost of inefficiency. Overlapping pays when redoing is cheaper than waiting. These are cases where it usually does not:
- Irreversible actions: production data migrations, contracts, physical manufacturing, public communications.
- Regulated settings where the evidence from one stage is a formal requirement for the next.
- When there is no way to capture signals in time: overlapping only adds work on unobserved assumptions.
- When capacity is so small that keeping all four processes active turns into constant context switching.
Hypotheses
The first four gather what the original proposal expects from synchronization. The others arose while formalizing it and working with AAA3. All of them may turn out false.
Time. When relevant information flows between processes without waiting for a phase to close, the system reaches a useful form sooner than when the same processes are organized in sequence.
Adaptability. Systems that evolve with synchronized processes take in changes in their environment at lower cost and with less delay.
Emergent quality. Continuous validation and optimization produce quality equal to or better than final verification, measured by the problems that reach the people using the system.
Emergence. Synchronization between processes increases the frequency of results that were not in the initial intent, and some of them turn out valuable.
AI agents. When AI agents make Ideate and Execute cheap, the bottleneck shifts toward Capture and toward human decision, and the quality of synchronization matters more than detailed planning.
Observability. If the system is described by a machine-readable artifact that keeps its history, the interaction between processes becomes measurable.
Capacity threshold. There is a threshold, in people or in available attention, below which keeping processes overlapped makes results worse because of the cost of switching context.
Record and rework. An explicit shared state (M1) reduces the rework caused by information that never reached another process, and reduces it by more than it costs to maintain.
What could be observed
None of these measures has been validated in a study yet, and all of them can be distorted once they become targets. We propose them as a starting point.
| Observable | What it describes | Hypothesis |
|---|---|---|
| Propagation latency | Time between one process producing relevant information and another process changing its work because of it. | H1, H2 |
| Coupling | How often one process's output actually changes what another does. | H4 |
| Traceable divergence | Differences between the recorded initial intent and the resulting system that can be traced back to an interaction between processes. | H4 |
| Adaptation latency | Time between a change in the environment and a change in the system in use. | H2 |
| Problems reaching use | Failures or dissatisfaction detected by the people using the system. | H3 |
| Unplanned rework | Work discarded because it rested on something another process already knew to be false. Deliberate explorations do not count. | H8 |
| Coordination cost | Time spent synchronizing over total time. | H7, H8 |
Open questions
The central question. How does synchronization between processes influence the evolution of a system, and under what conditions do results appear that were not foreseen? It is the main line of research.
How can valuable emergence be told apart from mere drift? An unforeseen result can be a finding or a detour; a criterion is needed that does not depend only on whoever judges it afterwards.
How can rework be measured without penalizing exploration? What is discarded after answering a question is not waste; what is discarded because nobody looked at an available signal is.
When one agent proposes an idea and another builds what tests it, who decides what counts as a result? Our provisional position is that it is always a person, but it is not clear how to do this without human review becoming the bottleneck again.
Is STD distinguishable, in practice, from a team that applies Scrum and Lean Startup well at the same time? It is the most serious criticism we know of.
AAA3 aims at reproducibility: the same document, with the same resources and parameters, should produce the same result (I7). If there is emergence, it happens in the authoring loop —people and models rewriting the document— and not in execution. Is that the right place for emergence in technical systems, or a limitation of the design?
What changes with AI agents
If a language model can write a developed idea or a whole module in minutes, Ideate and Execute become cheaper, but not equally so. Producing options becomes almost free; choosing among them does not. Building speeds up; observing whether what was built is useful, not as much. That is why H5 predicts that human work concentrates in Capture and in Optimize's decisions.
Synchronization itself changes too. An agent can propagate an observation to everything that depends on it in seconds, which makes question Q2 more visible: with near-immediate propagation, do findings increase, or does drift?
Limits of this formalization
- It grew mostly out of technology projects; it may not fit organizations, classrooms or creative processes.
- It risks reducing STD to its measurable consequences —catching errors earlier, redoing less— and losing sight of evolution and emergence. That reduction is exactly what version 0.1 of this site did, and we keep it on record.
- The proposed measures have not been validated.
- All available evidence comes from Braidata projects, with no comparison group.
References
- Reinertsen, D. G. (2009). The Principles of Product Development Flow. Celeritas.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate. IT Revolution.
- Nygard, M. (2011). Documenting Architecture Decisions.
- Popper, K. (1959). The Logic of Scientific Discovery. Hutchinson.
- Ries, E. (2011). The Lean Startup. Crown Business.
History
| Version | Date | Change |
|---|---|---|
| 0.1 | 2026-10-27 | Published as «Method»: it defined SyncThinkDesign by its mechanisms (record, minimum input, refutation). |
| 0.2 | 2026-10-28 | Becomes a layer subordinate to the foundations. The operational principles become optional mechanisms (M1–M7); hypotheses on adaptability, emergent quality and emergence are added, along with the central research question. |