Asks what entity is maintained by reciprocal constraints, how its health is observed, and whether persistence explains the system’s action dynamics.
Research documentation: this page interprets a cited research source and defines evidence requirements. It does not claim a released Teleodynamic AI implementation.
Beneficiary question
Name the entity whose continued organization explains the action dynamics. In the reviewed DE11 paper, the authors identify the hypothesis ensemble. Other implementations must not simply copy that answer.
Identity through change
Define which state changes preserve the beneficiary’s identity, which create a successor, and which constitute replacement or termination. A mutable graph without identity rules cannot support a precise persistence claim.
Constraint closure
Describe how one process creates or maintains boundary conditions required by another, and how the reciprocal process returns support. A one-way feedback controller with a designer-set target may be homeostatic without establishing teleodynamic closure.
Health and survival measures
The source uses hypothesis survival rate as one diagnostic for the DE11 ensemble. A different substrate needs its own declared health variables, acceptable range, replacement semantics, and observation window. Persistence alone is not evidence of useful organization.
Perturbation and recovery test
Apply bounded perturbations to structure, parameters, resource, and observations. Record whether reciprocal processes restore viable organization, reorganize into a declared successor, or fail. External operator repair must be labeled separately.
Evidence
Define persistence criteria, replacement rules, failure conditions, and tests showing that coupled constraints—not an external supervisor alone—maintain the beneficiary.
Scope
This starter page defines the questions, boundaries, evidence, and failure modes that should be recorded before a capability is presented as supported.
Engineering considerations
- Identify the source, version, target environment, and owner.
- Separate observed values from estimates and externally reported values.
- Record trade-offs, unsupported cases, and fallback behavior.
- Link performance statements to a compatible benchmark methodology.
Verification questions
- What exact artifact, revision, backend, and environment were reviewed?
- Which assumptions could change the result?
- Which data should be retained so another engineer can reproduce the conclusion?