InquirySpec - Ontological Boundary: Design-Based Research is the methodological frame in which tools, doctrine, Field Guide, and use co-evolve. - Not This: Not a closed product claim, vague humility theater, or an excuse to avoid artifact production. - Doctrine Dependencies: Design-Based Research, Reflexive Spec-Driven Design, Pathway to Incompleteness.
Working Definition
Design-Based Research is the methodological frame in which learnt.cloud treats designed artifacts as research instruments. The Field Guide, doctrine, workflow tooling, diagrams, prompts, and public drafts are not just outputs of a project. They are interventions placed into use, observed under constraint, interpreted, revised, and tested again.
The public point is simple: a system that claims to support accountable knowledge work has to show how its own claims are made accountable. Design-Based Research provides that discipline. It keeps the work from pretending to be a finished product while also refusing the opposite failure mode: endless reflection with no artifact sturdy enough to inspect.
In this sense, the Field Guide is not merely a library of essays and concepts. It is a research surface. Each essay, garden node, visual model, and verification script can expose whether the project is preserving context, carrying evidence, and making repair possible.
The Phenomenological Problem
The common institutional failure is closure theater.
A strategy memo is published. A dashboard is declared authoritative. A model output is treated as settled because it is clean enough to circulate. A methodology chapter describes ideals, while the actual process by which claims were formed remains scattered across chats, drafts, tickets, and private memory.
None of this requires deception. It is usually systemic gravity. The work has to move. People need a document, a plan, a decision, a release, a status update. The messy path by which the artifact was made is metabolically expensive to preserve, so the organization keeps the polished result and lets the research path decay.
Design-Based Research pushes against that decay. It asks the designed thing to stay answerable to the situation in which it was used. Did the artifact help people see the relevant context? Did it create new confusion? Did it make repair easier, or did it turn an unresolved question into an official-looking surface? Did the implementation expose a contradiction in the doctrine? Did public use show that the conceptual model was too thin?
Those questions are not decorative. They are the point of the method.
The Engineering Anchor
The internal meta-model frames learnt.cloud as a reflexive cyber-physical research system. That means the system studies its own development through designed interventions, implementation traces, public artifacts, and feedback loops. Its methodological stack blends Design-Based Research, iterative development, participatory research, embedded case study, and reflexive dialogic inquiry.
The core motion is Observation, Interpretation, and Application.
Observation gathers what happened: the draft, the prompt, the verifier output, the failed assumption, the versioned archive, the human objection, the broken link, the confusing phrase, the surface that did not render.
Interpretation asks what the observation means in relation to the system's principles. A failure may be a small defect, a bad phrase, a weak ontology, a missing scaffold, or a deeper mismatch between the public claim and the implementation underneath it.
Application changes the artifact, the specification, the tooling, or the research question. The change is then exposed to further observation.
This is why Reflexive Spec-Driven Design matters. Specifications are not treated as detached plans. They become instruments for forcing contact between intention and execution. This is also why Reflexive Dialogic Inquiry matters. Dialogue is not merely conversation around the work; it is one of the ways the work produces data about its own assumptions.
Design-Based Research gives those motions a research identity. It says that implementation is not beneath inquiry. Implementation is one of the places inquiry becomes legible.
Boundary Conditions
Design-Based Research is not a license to keep changing direction without accountability. The method requires artifacts that can be inspected, versioned, challenged, and improved. A vague aspiration cannot be studied in the same way a public node, scripted verifier, diagram, or workflow trace can be studied.
It is also not a claim that every artifact is equally mature. The method depends on visible incompleteness. A stub, draft, hydrated node, diagram grade, failed verifier, or ledger entry can all be legitimate research evidence if their status is explicit and their limits remain visible.
That boundary connects directly to the Pathway to Incompleteness. Incompleteness is not used as an excuse to avoid rigor. It is governed so the system can distinguish an unfinished research path from a completed claim.
The method also has a social boundary. The researcher, builder, and user are not always cleanly separate roles. In learnt.cloud, the Human Architect, Codex agents, doctrine files, public drafts, and generated surfaces all participate in a shared research ecology. This creates power and bias risks. Design-Based Research does not erase those risks. It makes them part of the accountable method by requiring traces, version history, critique, and repair routes.
Finally, Design-Based Research is not the whole project. It is a methodological layer in the Z-axis. It sits below the public Field Guide surface and above implementation details. It explains why the public artifact can be provisional without being careless, and why the engineering substrate can be experimental without being unaccountable.
Public Use
A reader does not need to learn the internal machinery to benefit from this node. The practical lesson is that public knowledge artifacts should carry their research posture.
If an essay makes a claim, the Field Guide should provide drill paths into the concepts that support it. If a garden node defines a term, it should show its boundary conditions and neighboring concepts. If a diagram explains a structure, it should remain connected to the written model it visualizes. If a verifier rejects a draft, the rejection should become evidence for the next revision rather than an invisible failure.
This posture keeps the Field Guide from becoming a static authority surface. It remains a field instrument: a way to test whether the project can preserve context, create accountable artifacts, support temporary cohorts, and keep contact with the situations it is trying to improve.
Drill Path
- Reflexive Dialogic Inquiry shows how human-machine conversation becomes a disciplined source of observation, interpretation, and application.
- Reflexive Spec-Driven Design shows how specifications become executable instruments rather than static requirements.
- Pathway to Incompleteness shows how provisional work can remain rigorous when its limits are named.
- Research Proposal Thread marks the deeper inquiry layer where the Field Guide's public artifacts connect to formal research framing.