Recursive Co-development

Not code first, documentation later

Co-development does not mean that an engine is built first and documented afterward. x64base, DotTalk++, and their documentation infrastructure are interdependent parts of one working system.

• x64base is the stateful database engine. It owns tables, fields, records, memos, indexes, relations, work areas, buffers, validation, and storage lifecycles.
• DotTalk++ is the engine's executable language and observation surface. It names operations, invokes engine behavior, exposes state, runs DotScript, and supplies the command boundary used by people, tests, GUIs, and automation.
• HELP, messages, metadata, contracts, SelfDoc, and MDO are the explanatory and verification structure. They preserve what operations are called, how they are used, what they mutate, their development status, and the evidence supporting them.

Documentation is therefore not merely a report about the engine. Its registrations, contracts, HELP identities, status records, validation reports, and missing-proof findings actively shape engine and runtime work. Source and runtime remain authoritative, but documentation completeness is itself an engineering test.

The engine/runtime/documentation triad

None of these layers substitutes for another. Together they make the system inspectable, teachable, testable, and increasingly self-describing.

Recursion is the operating model

x64base state and storage behavior
    -> DotTalk++ commands, scripts, inspection, and runtime evidence
    -> HELP + messages + registrations + usage/mutation contracts
    -> metadata normalization + SelfDoc preservation + MDO review
    -> manuals + diagrams + Laboratory Campus lessons + public pages
    -> review exposes drift, missing contracts, hidden behavior, or weak proof
    -> findings return to x64base, DotTalk++, metadata, and tests
    -> the next pass strengthens both behavior and explanation

The loop is recursive, but authority is not circular. Website prose does not become engine truth merely because it is published. Generated material cannot promote itself. Provenance, status labels, and human review govern every return path.

How documentation changes implementation

The documentation system applies concrete engineering pressure:

• a command without stable registration and HELP identity is incomplete;
• a mutator without usage, mutation, risk, stale, and dirty semantics is incomplete;
• an engine feature without an observable command or API path is difficult to teach or prove;
• a public claim without source or runtime provenance is blocked;
• contradictory HELP, metadata, and behavior become a drift finding;
• a missing failure transcript or canary becomes a proof requirement;
• manual and website organization expose gaps in the engine's conceptual model.

The constraint also works in reverse. Documentation cannot promise a transaction, index, field type, API, or command behavior that x64base and DotTalk++ do not actually support. That bidirectional constraint is the center of co-development.

Three cooperating systems

1. The x64base and DotTalk++ engine/runtime pair

x64base supplies database state and behavior. DotTalk++ makes that behavior readable, executable, scriptable, inspectable, and available to parallel CLI/TUI/GUI work. Their source and captured runtime evidence are primary technical truth.

2. Embedded documentation and Laboratory Campus

HELP, messages, metadata, contracts, SelfDoc, and MDO collect and preserve the system's own definitions and evidence. Laboratory Campus, with LabTalk retained as its project and historical name, turns reviewed material into diagrams, datasets, cases, demonstrations, labs, and lessons.

3. Manuals and website systems

Generated manuals, x64base.com, and dottalkpp.com publish reviewed derivatives. They are also active diagnostic surfaces: making the system coherent for readers reveals omissions and contradictions that recurse into the next development pass.

The websites are development instruments

The two sites operate at different scales:

A route that cannot be populated from governed evidence, a command family that cannot be organized coherently, an orphan diagram, a broken cross-site relationship, or contradictory status copy is a development finding. It returns through MDO and SelfDoc to the responsible metadata, HELP, source, test, manual, or website lane.

The websites do not redefine runtime truth. They test whether that truth is complete, reachable, internally consistent, and teachable. In that sense, x64base.com and dottalkpp.com are part of the recursive development apparatus, not advertisements added after the work is done.

Governing doctrine

Runtime proves, source defines, HELP explains, metadata organizes, SelfDoc preserves, MDO curates, and reviewed publication teaches.

Authority and safeguards

• Runtime and source remain authoritative for implementation claims.
• SelfDoc and metadata preserve provenance rather than manufacturing proof.
• Existing, developing, planned, and experimental work retain honest status.
• Website review may identify a source defect; changing prose alone does not repair it.
• Manual and website exchange follows governed simplex and duplex gates.
• Canonical README.* files are preserved and versioned when replaced.

Follow the system

• SelfDoc feed pipeline
• SelfDoc website publication
• HELP, message, and SelfDoc data-flow diagrams
• Laboratory Campus overview
• Important documents

This page is a reviewed derivative of labtalk/docs/co-development/recursive_coproject_model_v1.md in the implementation repository.