Architecture / method
How Tokimu makes architectural decisions¶
Tokimu treats architecture as something implementation must interrogate. A useful idea does not become foundational merely because it is convenient or common in other engines.
The evidence lifecycle¶
A concrete application or corpus exposes pressure.
The smallest honest example tests one boundary.
Independent producers or consumers reveal repeated semantics.
An Architectural Review records findings, uncertainty, and deferral.
Durable ownership is accepted only when the evidence warrants it.
A binding decision records the boundary and its consequences.
Corpus pressure¶
A focused corpus entry is an executable architectural sentence. It asks whether one behavior can be expressed naturally through the intended ownership boundary.
External data corpora ask whether implementations survive inputs Tokimu did not design for itself. Consumer corpora ask whether several contracts compose into an ordinary downstream application without privileged access.
Reviews are allowed to say “not yet”¶
Architectural Reviews preserve evidence without forcing a permanent answer. They can accept a direction while deferring crate extraction, reopen when new corpus pressure appears, or reject an attractive abstraction whose ownership remains unclear.
ADRs are binding¶
An ADR records an accepted architectural decision. Local implementation should not quietly work around it. If later evidence changes the decision, Tokimu updates or supersedes the ADR while retaining the earlier history.
Why the website exposes limitations¶
Tokimu distinguishes observations from guarantees. Public capability labels such as Renderable, Previewable, Inspected, Experimental, and Deferred communicate what the current evidence actually proves.
The goal is not to make every capability look complete. The goal is to make every claim inspectable.