From idea to practice

The operating playbook

One real request. Two bounded contributions. An explicit mapping, a test, and a useful return.

Version 1.0 · Proposed pilot method · 22 October 2026.

Use this playbook to complete one useful, voluntary knowledge exchange. It operationalizes Metapraxis as documentation, component definition, standardization, mapping, and evaluation rather than treating it as an abstract philosophy alone.

Before you start

Choose one real problem and two bounded contributions. Do not begin by asking someone to upload their entire archive or by generating a large knowledge graph without a use case.

  • Contributor: Supplies the method, context, evidence, and sharing boundaries.
  • Recipient or collaborator: States the task, attempts reuse, and returns a result.
  • Reviewer: Checks provenance, scope, and evaluation evidence; in a small pilot, this may be a participant with the conflict recorded.
  • Steward: Maintains versions, attribution, permissions, and correction notifications.

One person can hold multiple roles. Record who does what rather than assuming accountability emerges from the platform.

The cycle and its gates

Scroll the table sideways to see every column.

Stage Action Required artifact Gate before continuing
Collect Identify useful existing work and its origin Source inventory Authority to share is clear
Curate Distill one method and its context Knowledge module Another person can understand the intended use and limits
Connect Propose an explicit cross-domain relationship Transfer record Mapping is meaningful and permitted, with mismatches stated
Apply Build a bounded test artifact Output plus execution notes Test is run, not merely described
Learn Compare result against intended behavior Evaluation record Success, failure, and uncertainty are distinguished
Reinvest Return changes and agreed value Revised module and change log Someone can identify what improved and what remains open

Stop at a failed gate. A blocked exchange or disproved analogy can still produce a useful record, but should not be relabeled as a successful application.

Request template

Copy the fields below for a request. Ask for the smallest contribution that can answer the question or enable the next experiment.

Request title:
The task I am trying to complete:
What I have already tried:
The specific method or knowledge I need:
Available inputs and constraints:
What I can contribute in return:
Intended use: private learning / collaboration / public artifact / paid work
Deadline or time budget:
What would count as a useful response:
What should not be shared:

Knowledge module template

Record a partial contribution honestly. “Not known,” “not tested,” and “not included” are legitimate values.

Module ID and version:
Title:
Contributor and attribution preference:
Purpose and intended user:
Domain and terminology:
Source artifacts and provenance:
Primitives / components:
Relationships and dependencies:
Inputs and preconditions:
Operations / process:
Outputs / interfaces:
Principles and assumptions:
Claim types and supporting evidence:
Worked example:
Known exceptions / failure cases:
Tests already run:
Untested situations:
Private or excluded material:
Reuse rights and access terms:
Date reviewed / review trigger:
Contact or collaboration route:

Transfer record template

Distinguish analogy from executable compatibility. “Related to” is not the same claim as “can replace,” “is equivalent to,” or “has been validated in.”

Transfer ID:
Source module ID and version:
Destination module ID and version:
Relationship type:
Question or intended capability:
Concept / role mappings:
Relationship / operation mappings:
What must stay true:
What must change:
What does not map:
New assumptions introduced:
Potential contradictions:
Test or evaluation plan:
Evidence status:
Contributors, permissions, and attribution:
Resulting artifact:
Lessons returned to each module:

Agree before use, especially before publishing or building a commercial derivative. These are product-design prompts, not legal advice or a substitute for a suitable agreement.

  • Scope: Which material is being shared, with whom, and for what purpose?
  • Reuse: Can it be copied, adapted, redistributed, commercialized, or used for model training?
  • Attribution: How should the originator and subsequent contributors be named?
  • Compensation: Is this a gift, reciprocal exchange, license, commission, or revenue-sharing collaboration?
  • Ownership: Who owns the pre-existing inputs and the resulting work?
  • Privacy: What confidential, personal, or third-party material must be excluded?
  • Withdrawal: What future access can be stopped, and what happens to existing copies and authorized derivatives?
  • Disputes: Who resolves disagreements about provenance, quality, rights, or payment?

Ordinary discovery and inspiration should not automatically create a royalty obligation. Keep attribution, permitted use, and payment as related but separate records.

Evidence and quality review

Use statuses that describe actual evidence rather than a single opaque “brain score.” A contributor may be experienced while one of their proposed connections remains untested.

  • Draft: Scope and intended behavior are described.
  • Traceable: Sources, assumptions, and permissions are recorded.
  • Demonstrated: At least one worked example or test is available.
  • Reused: Another person has attempted application, with results recorded.
  • Validated for scope: The predeclared checks passed for specified conditions.
  • Contested, deprecated, or blocked: A problem is visible and dependent users are warned.

Never infer universal validity from a narrow test. Distinguish fabricated provenance from an honest failed experiment, and uncertainty from misconduct.

Failure-mode response

Scroll the table sideways to see every column.

Signal Response
Contributor fears extraction Reduce scope; clarify reciprocity, ownership, portability, and nonexclusive use
Module is incomplete Narrow its promise; add a worked example or mark it exploratory
Provenance appears fabricated Suspend reliance, investigate evidence, and notify affected users
Two frameworks conflict Preserve the disagreement and identify incompatible assumptions
Mapping only shares vocabulary Specify relational correspondence or downgrade to a discovery association
No one reuses the contribution Start from a real request rather than adding more content
Curation costs exceed benefits Simplify the module or stop the experiment
Platform becomes a bottleneck Test export, independent reuse, and an alternative exchange route
Contributor cannot revoke copies State the actual limit; do not promise retroactive erasure

Suggested first pilot

Use one musical timing module and one software-scheduling module to build a small audiovisual sequencer. This is a proposed experiment, not evidence that the transfer already works.

Map beats, bars, cues, events, and scheduling boundaries. Explicitly test where expressive timing, latency tolerance, and computational timing requirements differ.

Use the same task, source materials, and evaluation criteria for a baseline without the structured module and transfer record where practical. Record participant familiarity and other confounds rather than treating a small pilot as a causal proof.

Completion checklist

  • [ ] The request names a real task and a bounded need.
  • [ ] Contributions are voluntary and authorized.
  • [ ] Module scope, sources, assumptions, and limitations are explicit.
  • [ ] The transfer record distinguishes preserved structure from adaptation.
  • [ ] An actual test or application has been performed.
  • [ ] Results include failures and uncertainty, not only successes.
  • [ ] Revisions, attribution, and agreed returns are recorded.
  • [ ] A recipient can explain what is now reusable.
  • [ ] Corrections can reach dependent modules or users.
  • [ ] Both parties can decline another turn without losing unrelated access.

What to measure

Record time to validated reuse, output quality, curation and integration effort, useful corrections, and participant willingness to repeat. Count a completed turn only when a useful result or well-supported limitation has been returned to the system.

The operating principle is simple: share enough structure to enable new capability, without requiring people to surrender their knowledge or pretend it is complete.