The work begins before the representation, boundaries, and architecture are settled. These are the questions I return to across client products, manufacturing, and technical research; the cases alongside them show where the practice meets reality.
Start with what must become true, for whom, and when. A feature list is not yet a model of the obligation. Separate the outcome from the implementation someone has already imagined.
Give the problem an operative representation: the records, states, materials, and relationships that implementation must preserve. Look for the structure that crosses the product, design, and engineering boundaries.
Decide which part of the system can make each decision, which facts it may trust, and where responsibilities meet. Make uncertainty explicit before it becomes a silent assumption in code or on a production line.
Build the smallest representation that can meet reality. Carry it through interfaces, software, equipment, and process as the problem requires. Let the constraints change the implementation.
Observe what actually happened. Distinguish implementation from use, funding from revenue, and an author’s account from independent acceptance. Harden what proves useful; keep the open questions visible.
Turn repeated behavior into an explicit substrate: a runtime, workflow, or operating model. Document the boundaries and prepare the transfer. The aim is a system someone else can operate, rather than permanent dependence on its maker.
The goal is transfer: when the system is understood, ordinary execution can take over. Tell me what needs to become true →
A runtime for relationships. A protocol for semantic facts. A substrate for bounded agent work. Tools that cross into a desktop application.
Where does behavior belong when it lives between things?
A shared relational field represents bodies, relationships, constraints, and feedback; host adapters connect that model to interfaces and other surfaces.
This site runs the installed 0.9.3 runtime. The linked architecture describes the separately observed repository; public release does not establish external adoption.
Source observed 2026-10-05.
What can a tool actually know about a running system?
Runtime descriptors carry provenance, access policy, compatibility, and signed identity. Compiler facts, declarations, and observations remain distinguishable.
Experimental runtime protocol implementation. Compiler reflection remains a proposal; no compiler extractor or production HTTP service is implemented. Repository-reported checks were not rerun for this site audit.
Source observed 2026-10-05.
What must be explicit before an agent can own the next step?
Intent, authority, ready work, compiled context, evidence, and qualification become inspectable project machinery. Agent Control Plane supplies admission and bounded delivery decisions.
Candidate reusable substrate. Its v0.6.0 status reports mechanically tested tooling; unsteered behavioral transfer and comparative advantage remain unestablished. ACP implementation is supporting evidence, not a claim of client adoption.
Source observed 2026-10-05.
How does a desktop application become a tool an agent can use?
Layout, styles, assets, and export cross a structured tool boundary into InDesign, through host automation or an optional UXP bridge.
The two execution paths are documented and implemented; that does not establish every tool’s compatibility with both backends or external adoption.
Source observed 2026-10-05.
The executable runtime protocol in Reflective Rust sits beside a larger compiler-language proposal. The implementation boundary is explicit →
What does agreement between models actually justify?
A specified decision procedure separates evidence, pressure testing, human judgment, and prospective evaluation.
A public specification, architecture, and study design. It does not establish an implemented panel engine or a general performance benefit.
Source observed 2026-10-05.
The intellectual work continues in Distance from Gray and selected writing.