BTTMathLab/0200–0320 · Instruments & Canonical Probe Register

This register closes the callable references used by the experiment runtime. An instrument records or changes what can be observed; a probe is a deliberately chosen task variation used to reduce uncertainty about the learner’s present mathematical state.

BTTMathLab/0200–0209 · Instrument Registry

• BTTMathLab/0200 — Instrument Registry: canonical index for reusable MathLab observation and test instruments.
• BTTMathLab/0201 — Attempt Recorder: preserve the learner’s unedited source attempt, sequence and support state.
• BTTMathLab/0202 — First-Wrong-Move Locator: identify the earliest observable divergence rather than only the final wrong answer.
• BTTMathLab/0203 — Dependency Tracer: test whether an earlier capability is materially constraining the current task.
• BTTMathLab/0204 — Representation Instrument: present or capture the same mathematical object across symbolic, verbal, numerical, tabular, graphical or diagrammatic forms.
• BTTMathLab/0205 — Support Meter: record the amount and type of assistance required before, during and after an attempt.
• BTTMathLab/0206 — Transfer Instrument: alter non-essential surface features while preserving the declared mathematical invariant.
• BTTMathLab/0207 — Recovery Instrument: observe detection, rollback and reconstruction after a false start or error.
• BTTMathLab/0208 — Retention Clock: schedule and record delayed return without re-teaching first.
• BTTMathLab/0209 — Stress Dial: introduce one controlled load variable at a time after basic mathematical control is secure.

BTTMathLab/0301–0320 · Canonical Diagnostic Probes

• 0301 — No-Help First Attempt: observe what the learner can initiate before assistance changes the state.
• 0302 — Chapter-Heading Removal: remove the topic label to test recognition independently of worksheet cues.
• 0303 — Same Mathematics, New Numbers: preserve structure while changing numerical values.
• 0304 — Same Mathematics, New Words: preserve the governing relation while changing wording or context surface.
• 0305 — Same Mathematics, New Representation: change form while preserving the declared invariant.
• 0306 — Explain-Why Probe: require justification for a step, relation or transformation.
• 0307 — Predict-Before-Calculate Probe: ask for direction, sign, range, shape or approximate behaviour before execution.
• 0308 — Deliberate-Error Probe: present a plausible incorrect route and ask the learner to detect and repair it.
• 0309 — Missing-Step Probe: remove one consequential line and require reconstruction.
• 0310 — Reverse-Direction Probe: invert the usual direction of the task where mathematically meaningful.
• 0311 — Multiple-Method Probe: require or compare more than one valid route to the same mathematical object.
• 0312 — Method-Selection Probe: present plausible competing methods and test independent choice.
• 0313 — Minimal-Hint Probe: supply exactly one small cue and observe whether control restarts.
• 0314 — False-Friend Probe: use a familiar-looking surface whose correct mathematical structure differs from the expected pattern.
• 0315 — Structural-Twin Probe: use a different-looking task with the same underlying structure.
• 0316 — Boundary-Case Probe: test limits, restrictions, exceptional values or edge conditions.
• 0317 — Counterexample Probe: challenge an overgeneralised rule with a case that forces revision.
• 0318 — Dependency-Removal Probe: temporarily supply or simplify a suspected prerequisite to see whether the target capability then operates.
• 0319 — Cognitive-Load-Reduction Probe: reduce non-essential working demand without changing the target mathematics.
• 0320 — Delayed-Recall Probe: return after an interval without re-teaching and test retrieval before reconstruction.

BTTMathLab/0999 · Experiment Registry & Boot Closure

BTTMathLab/0999 is the canonical registry for the experiment family. Individual experiments begin at BTTMathLab/1000; therefore BTTMathLab/1000 — The Blank First Line remains the first experiment and no identifier is overloaded.

BTTMATHLAB_BOOT_PATCH_V0_2
EXAMINATION_OWNER = /mathematics-examination-craft/
INSTRUMENT_REGISTRY = BTTMathLab/0200
PROBE_REGISTRY = BTTMathLab/0300
EXPERIMENT_REGISTRY = BTTMathLab/0999
EXPERIMENTS_BEGIN = BTTMathLab/1000

RULE:
  IF mathematics_is_stable AND failure_is_examination_environment:
    RETURN_TO = EXAMINATION_OWNER
  IF experiment_calls_object:
    OBJECT_MUST_RESOLVE_TO_REGISTERED_ID = TRUE

BTTMathLab/0400–0499 · Intervention Library

An intervention is a controlled change introduced only after the Lab has enough evidence to justify it. The governing rule is minimum sufficient assistance: change the smallest useful thing, then return control to the learner and observe what happens next.

• BTTMathLab/0400 — Intervention Registry: canonical owner for Lab interventions.
• BTTMathLab/0401 — WAIT: preserve the problem state and allow independent continuation before adding help.
• BTTMathLab/0402 — ASK: use one discriminating question to expose the learner’s present model.
• BTTMathLab/0403 — REFRAME: restate the same mathematical object without supplying the method.
• BTTMathLab/0404 — CUE: direct attention to a relevant feature while withholding the next operation.
• BTTMathLab/0405 — HINT: reveal one useful relation or next decision, not the complete route.
• BTTMathLab/0406 — PARTIAL MODEL: demonstrate only the missing local structure, then hand the problem back.
• BTTMathLab/0407 — PREREQUISITE REPAIR: temporarily step backward to the earliest weak dependency identified by the Lab.
• BTTMathLab/0408 — REPRESENTATION CHANGE: move the same mathematics into a form that makes the relationship more visible.
• BTTMathLab/0409 — CONTRAST CASE: compare two nearby cases so the structural distinction becomes observable.
• BTTMathLab/0410 — COUNTEREXAMPLE: challenge an overgeneralised rule with a case that forces revision.
• BTTMathLab/0411 — GUIDED RECONSTRUCTION: rebuild the reasoning with the learner supplying increasing portions of the route.
• BTTMathLab/0412 — INDEPENDENT REATTEMPT: remove the intervention and require a fresh attempt.
• BTTMathLab/0413 — FADE: systematically reduce prompts across repeated successful attempts.
• BTTMathLab/0414 — RETURN TO OWNER: send the learner back to the canonical course, topic, practice or examination route once the Lab no longer owns the active problem.

Runtime intervention rule

IF evidence_is_insufficient:
  PROBE
ELSE:
  SELECT smallest_justified_intervention
  APPLY once
  RETURN_CONTROL_TO_LEARNER
  OBSERVE
  VALIDATE

DO_NOT:
  explain_everything_by_default
  replace_course_owner
  hide_failed_intervention
  increase_help_without_new_evidence

The Intervention Library calls the existing Mathematics HELP Runtime for help escalation logic. MathLab records why an intervention was selected, what changed, what remained unresolved and whether assistance could subsequently be reduced.

BTTMathLab/0600–0699 · Representation & Transformation Runtime

Representation is not decoration. A mathematical object can appear as symbols, words, tables, graphs, diagrams, coordinates or other forms while preserving the same underlying relationship. The runtime therefore separates surface form from invariant structure and refuses transformations that change the mathematics without declaring that change.

• BTTMathLab/0600 — Representation Registry: canonical index for representation and transformation objects.
• BTTMathLab/0601 — Symbolic Form: expressions, equations, inequalities, notation and algebraic structure.
• BTTMathLab/0602 — Verbal Form: mathematical relationships expressed in natural language.
• BTTMathLab/0603 — Table Form: ordered values, finite samples and pattern-visible data structures.
• BTTMathLab/0604 — Graphical Form: coordinate, function, statistical and geometric graph representations.
• BTTMathLab/0605 — Diagrammatic Form: geometry, bar models, schematics and relational diagrams.
• BTTMathLab/0606 — Numerical Form: instantiated values used to test or exemplify a general relation.
• BTTMathLab/0607 — General Form: the parameterised or abstract structure that survives specific examples.
• BTTMathLab/0608 — Representation Translation: move between two valid forms while preserving declared invariants.
• BTTMathLab/0609 — Bidirectional Translation: require the learner or AI to reconstruct the source relation from the destination form.
• BTTMathLab/0610 — Invariant Register: declare what must remain true during a transformation.
• BTTMathLab/0611 — Legal Transformation: change form using operations that preserve the required invariant.
• BTTMathLab/0612 — Conditional Transformation: permit a transformation only under explicit restrictions or domain conditions.
• BTTMathLab/0613 — Information Loss Check: detect when a representation or operation loses solutions, cases, sign, orientation, scale, units or domain information.
• BTTMathLab/0614 — Information Gain Warning: detect when a transformed statement accidentally admits cases not allowed by the source.
• BTTMathLab/0615 — Equivalent Surface Test: test whether two different forms encode the same mathematical object.
• BTTMathLab/0616 — Non-Equivalent Twin Test: detect visually similar forms with different mathematical meaning.
• BTTMathLab/0617 — Representation Preference: record which forms increase or reduce cognitive cost for the learner without declaring one form universally superior.
• BTTMathLab/0618 — Multi-Representation Validation: require successful movement across more than one form before claiming robust understanding where appropriate.

Invariant-preservation contract

REPRESENTATION_RUNTIME_V0_1

SOURCE_OBJECT = declared
SOURCE_FORM = declared
TARGET_FORM = declared
INVARIANTS = declared
RESTRICTIONS = declared

TRANSFORM:
  preserve(INVARIANTS)
  preserve(RESTRICTIONS)
  record(information_lost)
  record(information_added)
  verify(reverse_path_if_required)

IF invariant_broken:
  STATE = NON_EQUIVALENT
  DO_NOT_LABEL_AS_SAME_MATHEMATICS

IF restriction_hidden:
  STATE = UNSAFE_TRANSFORMATION
  RETURN_TO_SOURCE

IF equivalent AND reversible_enough_for_task:
  STATE = REPRESENTATION_VALID

How the runtime is used

A learner who cannot use an equation may still understand the relation through a graph or table. The Lab may therefore change representation as an intervention, then validate whether the learner can return to the original form. Conversely, a learner who succeeds only in one familiar representation has not yet demonstrated transfer.

This runtime connects directly to BTTMathLab/0104 — Representation Studio, BTTMathLab/0204 — Representation Instrument, BTTMathLab/0305 — Same Mathematics, New Representation Probe, BTTMathLab/0408 — Representation Change and BTTMathLab/0504 — Representation Validation. The objects are intentionally reusable rather than rewritten inside each experiment.

BTTMathLab/0800–0899 · Transfer, Retention & Stress Runtime

Local success is not enough. The Lab now tests whether mathematical control survives changes in surface, elapsed time, dependency depth, topic mixture and performance load. Transfer, retention and stress are treated as separate dimensions because a learner may pass one and fail another.

• BTTMathLab/0800 — Transfer/Retention/Stress Registry: canonical index for durability and robustness testing.
• BTTMathLab/0801 — Near Transfer: same structure with modest changes in numbers, wording or layout.
• BTTMathLab/0802 — Farther Transfer: same underlying mathematics embedded in a less familiar surface or context.
• BTTMathLab/0803 — Representation Transfer: preserve the relation while changing symbol, graph, table, diagram or verbal form.
• BTTMathLab/0804 — Topic-Hidden Transfer: remove chapter labels and obvious method cues.
• BTTMathLab/0805 — Mixed-Topic Transfer: place the target mathematics among plausible competing methods.
• BTTMathLab/0806 — Multi-Step Transfer: require the target capability to operate inside a longer dependency chain.
• BTTMathLab/0807 — Context Transfer: move a mathematical relation into a new application without changing its governing structure.
• BTTMathLab/0810 — Retention Registry: canonical owner for delayed-return tests.
• BTTMathLab/0811 — Same-Lesson Return: reintroduce the object after intervening work.
• BTTMathLab/0812 — Next-Lesson Return: test retrieval before re-teaching.
• BTTMathLab/0813 — Seven-Day Return: test durability after approximately one week where appropriate.
• BTTMathLab/0814 — Extended Return: test after a longer interval chosen for the learner and syllabus context.
• BTTMathLab/0815 — Mixed-Retrieval Return: recover the object from a broader set rather than a dedicated topic set.
• BTTMathLab/0820 — Stress Registry: canonical owner for controlled-load testing.
• BTTMathLab/0821 — Support Withdrawal Stress: reduce prompts without changing the mathematics.
• BTTMathLab/0822 — Recognition Stress: remove headings, sequence cues and obvious topic grouping.
• BTTMathLab/0823 — Dependency Stress: increase the number of prerequisite capabilities that must remain stable.
• BTTMathLab/0824 — Representation Stress: introduce a less preferred but mathematically valid representation.
• BTTMathLab/0825 — Distraction Stress: include irrelevant or competing information without changing the target relation.
• BTTMathLab/0826 — Time Stress: introduce time constraints only after the mathematics itself is sufficiently stable.
• BTTMathLab/0827 — Examination Mix Stress: combine topic selection, navigation, timing and checking demands.
• BTTMathLab/0828 — Recovery Stress: require the learner to recover after a deliberate or naturally occurring false start.
• BTTMathLab/0830 — Stress Ceiling: identify the point at which reliable mathematical control begins to degrade.
• BTTMathLab/0831 — Stress Backoff: reduce load after breakdown and retest at the last stable level instead of simply pushing harder.

Durability runtime

DURABILITY_RECORD
  mathematical_object
  baseline_state
  transfer_level
  transfer_result
  retention_interval
  retention_result
  stress_dimensions[]
  stress_level
  breakdown_point
  recovery_result
  support_required
  validation_state
  canonical_return_owner

RULES:
  DO_NOT_ADD_TIME_PRESSURE_BEFORE_BASIC_CONTROL
  CHANGE_ONE_PRIMARY_STRESS_DIMENSION_WHEN_DIAGNOSING
  PRESERVE_MATHEMATICAL_OBJECT_DURING_TRANSFER_TEST
  FAILED_STRESS_TEST != LOST_KNOWLEDGE_AUTOMATICALLY
  RETENTION_FAILURE_REQUIRES_NEW_EVIDENCE_BEFORE_RETEACHING_ALL

IF transfer_fails:
  classify_transfer_failure
  route_to_probe_or_representation_runtime

IF retention_fails:
  distinguish_retrieval_from_concept_loss

IF stress_fails:
  record_breakdown_point
  BACKOFF
  diagnose_which_component_failed

IF transfer AND retention AND independence survive required_load:
  durability_state = ROBUST_FOR_CURRENT_CONTEXT

Plumbing back to BTT

The Stress Runtime does not take over examination teaching. Once the Lab establishes that the underlying Mathematics is stable, examination-specific timing, sequencing and paper-navigation work returns to Mathematics Examination Craft. Likewise, content weaknesses return to the relevant course owner or the Knowledge Warehouse. MathLab owns the test of robustness, not every downstream lesson.

This layer connects BTTMathLab/0108 — Transfer Tunnel, 0109 — Retention Chamber, 0110 — Mathematical Stress Chamber, the Transfer/Retention/Stress instruments, the Validation Runtime and the Error Runtime into one reusable durability pathway.

BTTMathLab/1020–1099 · Student-Input Routing Runtime

The learner does not need to know the internal name of a failure state. The routing layer accepts ordinary statements, narrows them into testable possibilities, then selects the smallest experiment that can reduce uncertainty. When the input is too ambiguous, it routes through Mathematics HELP or Diagnosis instead of guessing.

• BTTMathLab/1020 — Student-Input Router: canonical entry router for ordinary learner statements.
• BTTMathLab/1021 — Cannot Start Route: “I don’t know how to start.” Primary experiment: 1000 — The Blank First Line.
• BTTMathLab/1022 — Topical-But-Not-Mixed Route: “I can do worksheets but not papers.” Primary experiment: 1002 — Remove the Chapter Heading; follow with mixed-topic transfer only if needed.
• BTTMathLab/1023 — Understand-Then-Forget Route: “I understand in class but forget later.” Primary experiment: 1008 — Return Seven Days Later; distinguish retrieval from concept loss before reteaching.
• BTTMathLab/1024 — Careless-Mistake Claim Route: “I keep making careless mistakes.” Do not accept the label as diagnosis. Begin with source working and route to 1004 — Wrong Answer, Good Mathematics or the Error Runtime depending on evidence.
• BTTMathLab/1025 — Correct-But-Unsure Route: “I got it right but I don’t really know why.” Primary experiment: 1003 — Correct Answer, Fragile Method.
• BTTMathLab/1026 — Too-Slow Route: “I know how, but I’m too slow.” First establish stable ordinary control; then use efficiency evidence and 1010 — Mathematics Under Time only when time is the justified variable.
• BTTMathLab/1027 — Needs-Hints Route: “I can do it when someone gives me a hint.” Primary experiment: 1005 — Remove One Hint.
• BTTMathLab/1028 — Wording-Changes Route: “I can do the normal question but not when they phrase it differently.” Primary experiment: 1001 — Same Mathematics, Different Surface.
• BTTMathLab/1029 — Graph/Equation Mismatch Route: “I understand the equation but not the graph,” or the reverse. Primary experiment: 1006 — Show It Another Way.
• BTTMathLab/1030 — Algebra-Step-Why Route: “I know the step but not why it works.” Primary experiment: 1007 — Explain the Equality.
• BTTMathLab/1031 — False-Start Route: “Once I get stuck or go wrong, I cannot recover.” Primary experiment: 1009 — Recover From the False Start.
• BTTMathLab/1032 — Exam-Only Breakdown Route: “I can do it at home but not in the exam.” First verify ordinary control; then route to 1010 — Mathematics Under Time and, once the Mathematics is stable, hand over to Mathematics Examination Craft.
• BTTMathLab/1033 — Ready-to-Prove Route: “I think I can do this on my own now.” Primary experiment: 1011 — Independent Release Test.
• BTTMathLab/1034 — Ambiguous Input Route: when several routes remain plausible, ask one discriminating question through Mathematics HELP or Diagnosis before selecting an experiment.

Machine routing contract

STUDENT_INPUT_ROUTER_V0_1

INPUT = learner_statement + available_evidence

ROUTE:
  parse_without_diagnosing
  identify_candidate_routes[]
  if one_high_confidence_route:
    select_smallest_experiment
  else:
    ask_one_discriminating_question
    route_via_HELP_or_DIAGNOSIS

GUARDRAILS:
  STUDENT_LABEL != FAILURE_STATE
  "CARELESS" != ACCEPTED_DIAGNOSIS
  "SLOW" != AUTOMATIC_TIME_PROBLEM
  "FORGET" != AUTOMATIC_CONCEPT_LOSS
  "BAD_AT_MATH" != ROUTABLE_STATE

OUTPUT:
  selected_experiment_id
  reason
  evidence_needed
  fallback_owner
  return_owner

Public entry language

The Lab can therefore offer human-readable entry doors such as I don’t know how to start, I keep making the same mistake, I understand but forget, I need hints, I can do topical questions but not papers, I am too slow, the wording throws me, and I think I am ready to do this independently. These doors are not diagnoses. They are routing surfaces into the experimental system.

Plumbing rule: the router may enter from the Mathematics Hub, HELP, Diagnosis, a course page or a future contextual Lab link. It must always preserve the originating owner and return the learner there, or to another explicit canonical owner, when the experiment is finished.

BTTMathLab/1200–1299 · Deep-Page Discovery & Estate Resolution Runtime

An AI may arrive on a Mathematics article written before MathLab existed. It should not require the learner to restart at the estate homepage. This runtime resolves the local page upward to the nearest trustworthy owner, preserves the source URL and page family, then boots MathLab only if the active job is experimental investigation.

• BTTMathLab/1200 — Deep-Page Discovery Bridge: directory-level recovery route for older Mathematics pages.
• BTTMathLab/1201 — Local Owner Check: prefer an owner explicitly declared by the current page.
• BTTMathLab/1202 — Parent/Ancestor Resolution: use page hierarchy when it identifies a stronger owner than title inference.
• BTTMathLab/1203 — Directory Resolution: use the Complete Mathematics Article Directory when local ownership is absent or stale.
• BTTMathLab/1204 — Hub Resolution: fall back to the Singapore Mathematics Hub for estate-level navigation.
• BTTMathLab/1205 — Page-Family Classifier: distinguish course, tuition, tutorial, tutor, engineer, knowledge, diagnosis, examination, reflective article, applied Mathematics and other families before routing.
• BTTMathLab/1206 — Source Preservation: carry the deep page URL/title into the ingress receipt so the return path is not lost.
• BTTMathLab/1207 — Investigation Gate: MathLab is called only when learner working must be experimentally discriminated, changed or validated.
• BTTMathLab/1208 — Non-Lab Pass-Through: informational, curriculum, commercial, knowledge-reference or ordinary navigation jobs stay with their resolved owners.
• BTTMathLab/1209 — Stale Runtime Adapter: older runtime pages resolve forward to Boot V1 while retaining their original owner identity.
• BTTMathLab/1210 — Unknown Owner State: if no trustworthy owner resolves, preserve UNKNOWN and route to the Mathematics Hub rather than inventing one.

DEEP_PAGE_RESOLVER_V0_1

INPUT:
  current_url
  current_title
  parent_chain[]
  local_links[]
  declared_owner
  learner_job

RESOLVE_ORDER:
  1 declared_local_owner
  2 registered_parent_or_ancestor_owner
  3 mathematics_article_directory
  4 mathematics_hub
  5 UNKNOWN

IF learner_job == experimental_investigation:
  preserve(source_url)
  preserve(resolved_owner)
  BOOT BTTMathLab/0022
ELSE:
  stay_with(resolved_owner)

GUARDRAILS:
  TITLE_MATCH != CANONICAL_OWNERSHIP
  OLD_PAGE != OBSOLETE_PAGE
  DEEP_PAGE != ORPHAN_IF_DIRECTORY_RESOLVES
  DO_NOT_FORCE_LAB_ENTRY
  DO_NOT_REWRITE_OLD_ARTICLE_TO_GAIN_DISCOVERY
  DO_NOT_LOSE_RETURN_PATH

The Complete Mathematics Article Directory now carries the public discovery bridge. This lets hundreds of older Mathematics resources remain intact while still participating in the newer runtime architecture through a shared recovery surface.

BTTMathLab/1400–1499 · Runtime Receipts, Provenance & Replay

A MathLab decision should be reconstructable after the lesson, after a later contradiction, and after the runtime itself has changed. This layer binds evidence, object IDs, owner routes and runtime versions into a replayable trace without pretending that a replay is new learner evidence.

• BTTMathLab/1400 — Provenance Registry: canonical index for trace, replay and receipt lineage.
• BTTMathLab/1401 — Investigation Run ID: permanent identifier for one bounded Lab run.
• BTTMathLab/1402 — Runtime Version Stamp: records the boot contract and declared object range used for the run.
• BTTMathLab/1403 — Source Provenance: records ingress owner, source URL, task, attempt and carried context.
• BTTMathLab/1404 — Object Call Trace: ordered list of probes, interventions, validators, transformations and release objects actually called.
• BTTMathLab/1405 — Decision Trace: records why each next object was selected and what competing route was rejected.
• BTTMathLab/1406 — Evidence Lineage: connects observations and receipts back to their source attempt without rewriting the source.
• BTTMathLab/1407 — Contradiction Lineage: records later evidence that weakens, reverses or reopens an earlier conclusion.
• BTTMathLab/1408 — Owner Lineage: records ingress owner, temporary Lab ownership and final handover owner.
• BTTMathLab/1409 — Replay Contract: reconstructs the prior runtime path for audit or explanation without silently rerunning the learner.
• BTTMathLab/1410 — Replay Result: SAME_PATH, DIFFERENT_PATH_UNDER_CURRENT_RUNTIME, UNRESOLVED_OBJECT, OWNER_CHANGED, INSUFFICIENT_ARCHIVE.
• BTTMathLab/1411 — Historical Runtime Replay: interpret the run under the runtime version originally stamped on the receipt.
• BTTMathLab/1412 — Current Runtime Replay: compare the same archived evidence against the current boot contract to detect architectural drift.
• BTTMathLab/1413 — Non-Reexecution Guard: replay of archived evidence must not be represented as a fresh learner test.
• BTTMathLab/1414 — Receipt Chain: binds Ingress Receipt → Evidence Receipt → Handover Receipt → Health/Upgrade Receipt where applicable.
• BTTMathLab/1415 — Missing Provenance State: preserve UNKNOWN when source evidence or version context is incomplete.
• BTTMathLab/1420 — Compact Replay Routine: machine-readable audit procedure.

MATHLAB_RUN_RECEIPT
  run_id
  timestamp
  boot_id
  boot_string
  declared_object_range
  ingress_receipt
  source_owner
  source_url
  source_task
  source_attempt_reference
  learner_statement
  candidate_failure_states[]
  object_call_trace[]
  interventions[]
  evidence_receipt_id
  validation_state
  contradictory_evidence[]
  release_state
  handover_receipt_id
  destination_owner
  unresolved_risks[]

REPLAY_V0_1:
  load(run_receipt)
  verify(source_provenance)
  verify(object_ids)
  verify(owner_lineage)

  historical_path = interpret_with(stamped_runtime)
  current_path = interpret_with(current_boot)

  compare(historical_path, current_path)
  record(differences)

GUARDRAILS:
  REPLAY != NEW_OBSERVATION
  ARCHIVED_SUCCESS != CURRENT_MASTERY
  MISSING_SOURCE != ASSUME_SOURCE
  VERSION_CHANGE != PAST_ERROR_AUTOMATICALLY
  OWNER_CHANGE_REQUIRES_EXPLICIT_MIGRATION
  PRESERVE_OLD_RECEIPTS
  APPEND_NEW_RECEIPTS

IF object_no_longer_resolves:
  result = UNRESOLVED_OBJECT
  call BTTMathLab/1320

IF current_runtime_selects_different_path:
  preserve_both
  explain_version_difference
  do_not_rewrite_historical_receipt

IF new_learner_evidence_required:
  STOP_REPLAY
  create_new_run_id

Why replay matters

A later tutor or AI can now ask: What did we know then? Which probe produced that conclusion? How much help was present? Which runtime version selected the route? Has the architecture changed since? Replay answers those questions while keeping historical evidence separate from a fresh test of the learner.

Privacy boundary: public MathLab defines the receipt schema and replay rules. Learner-specific receipts, attempts and identifying details belong in an appropriate private data store, not in the public page.

BTTMathLab/1600–1699 · Experiment Selection & Information-Gain Runtime

The Lab should not ask more questions than the evidence requires. This runtime selects the smallest probe or experiment expected to separate the leading explanations, while accounting for learner cost, contamination risk and the value of preserving an untouched state.

• BTTMathLab/1600 — Selection Registry: canonical index for experiment-selection objects.
• BTTMathLab/1601 — Candidate Hypothesis Set: preserve the plausible failure states still consistent with current evidence.
• BTTMathLab/1602 — Discriminating Power: estimate how strongly a probe can separate the leading hypotheses.
• BTTMathLab/1603 — Evidence Cost: estimate time, cognitive load, learner frustration and state contamination introduced by the probe.
• BTTMathLab/1604 — State Preservation Value: prefer observing the untouched learner state before help changes it when that evidence is still available.
• BTTMathLab/1605 — Expected Information Gain: rank candidate probes by likely reduction in uncertainty, not by how much content they cover.
• BTTMathLab/1606 — Minimum Sufficient Probe: choose the least costly probe expected to answer the active diagnostic question.
• BTTMathLab/1607 — Probe Redundancy Check: do not repeat a probe whose likely outcomes are already represented by adequate evidence.
• BTTMathLab/1608 — Contamination Guard: recognise that hints, explanations and repeated exposure can change the state being measured.
• BTTMathLab/1609 — Stop-Testing Rule: stop probing when remaining uncertainty no longer changes the justified action.
• BTTMathLab/1610 — One-Question Narrowing: when several routes remain plausible, prefer one high-value discriminating question before a larger battery.
• BTTMathLab/1611 — Tie-Break Rule: when probes have similar information value, prefer lower learner cost, lower contamination and easier reversibility.
• BTTMathLab/1612 — Exploration Escalation: widen the experiment only when the smallest probe fails to resolve the decision boundary.
• BTTMathLab/1613 — Action-Relevant Uncertainty: distinguish uncertainty that matters for the next action from uncertainty that can safely remain unresolved.
• BTTMathLab/1614 — Unknown Preservation: no forced diagnosis merely to finish the routing tree.
• BTTMathLab/1620 — Selection Receipt: machine-readable record of why one experiment was chosen over alternatives.

EXPERIMENT_SELECTION_V0_1

INPUT:
  candidate_hypotheses[]
  existing_evidence[]
  candidate_probes[]
  learner_cost_budget
  contamination_risk
  action_threshold

FOR each probe:
  estimate(discriminating_power)
  estimate(evidence_cost)
  estimate(contamination_risk)
  estimate(expected_information_gain)

SELECT probe WHERE:
  action_relevant_information_gain is highest
  AND learner_cost is justified
  AND no lower-cost probe is sufficient

AFTER_RESULT:
  update(candidate_hypotheses)
  update(confidence)

IF next_action_is_same_across_remaining_hypotheses:
  STOP_TESTING

IF uncertainty_changes_action:
  continue_with_smallest_next_probe

GUARDRAILS:
  MORE_TESTS != BETTER_DIAGNOSIS
  LONGER_BATTERY != HIGHER_CONFIDENCE_AUTOMATICALLY
  HINT_CAN_CONTAMINATE_BASELINE
  REPEATED_EXPOSURE_CAN_CONTAMINATE_TRANSFER
  INFORMATION_GAIN_DOES_NOT_OVERRIDE_LEARNER_COST
  PRESERVE_UNKNOWN_WHEN_ACTION_CAN_PROCEED_SAFELY

BTTMathLab/1620 · Selection Receipt

SELECTION_RECEIPT
  run_id
  active_question
  candidate_hypotheses[]
  candidate_probes[]
  selected_probe_or_experiment
  discriminating_reason
  evidence_cost
  contamination_risk
  alternatives_rejected[]
  stop_condition
  unresolved_but_action_irrelevant[]

This layer operationalises the existing HELP principle of narrowing before escalation. HELP retains ownership of assistance decisions; MathLab uses information gain to decide which bounded experiment can supply the missing evidence with the least unnecessary disturbance.

BTTMathLab/1800–1899 · Tutor + AI Collaboration Runtime

AI can extend observation, routing and replay, but it does not replace tutor responsibility. This runtime separates what AI may propose, what it may execute inside bounded MathLab contracts, what requires tutor review, and how disagreement or uncertainty is handled without hiding either side.

• BTTMathLab/1800 — Collaboration Registry: canonical index for tutor–AI authority boundaries.
• BTTMathLab/1801 — Tutor Authority: the human tutor remains responsible for classroom judgment, learner welfare, interpretation of context and final pedagogical action.
• BTTMathLab/1802 — AI Observation Assist: AI may structure source attempts, detect candidate patterns and surface missing evidence without declaring a diagnosis from one signal.
• BTTMathLab/1803 — AI Routing Assist: AI may propose the smallest experiment or probe under Boot V1 and the information-gain runtime.
• BTTMathLab/1804 — AI Bounded Execution: AI may execute only explicitly allowed runtime objects within declared owner and privacy boundaries.
• BTTMathLab/1805 — Tutor Review Gate: interventions with meaningful pedagogical consequence may require tutor acceptance before execution.
• BTTMathLab/1806 — Tutor Override: the tutor may reject an AI route; the override should record reason rather than silently erase the AI recommendation.
• BTTMathLab/1807 — AI Challenge Back: AI may surface contradictory evidence or ask for review when a human action conflicts with preserved evidence, without claiming superior authority.
• BTTMathLab/1808 — Uncertainty Surface: AI must expose LOW/MODERATE/HIGH confidence and UNKNOWN states rather than laundering uncertainty into fluent language.
• BTTMathLab/1809 — Evidence Before Persuasion: disagreement is resolved by new evidence, owner rules or explicit tutor decision—not by verbosity or model confidence.
• BTTMathLab/1810 — Human-Only Context: emotional, family, classroom, developmental or situational context that is not captured in the runtime remains available to tutor judgment and should not be overwritten by sparse machine evidence.
• BTTMathLab/1811 — AI Scope Boundary: AI must hand over jobs outside MathLab’s declared capability or ownership.
• BTTMathLab/1812 — Privacy Boundary: learner-specific attempts, receipts and identifiers remain in approved private storage; the public runtime contains schemas only.
• BTTMathLab/1813 — Three-Student Coordination Assist: AI may help track parallel queues and evidence chains, but may not collapse the three learners into one state.
• BTTMathLab/1814 — Explainable Recommendation: every AI route should state selected object, evidence used, unresolved uncertainty and canonical return owner.
• BTTMathLab/1815 — Override Replay: later audits may compare AI recommendation, tutor override and resulting learner evidence without rewriting either historical decision.
• BTTMathLab/1816 — Model Substitution Rule: a different model may execute the same capability contract; model identity does not redefine the architecture.
• BTTMathLab/1817 — Failure-to-Human Rule: unresolved owner conflict, repeated contradictory evidence, unsafe ambiguity or runtime failure escalates to tutor review rather than autonomous persistence.
• BTTMathLab/1820 — Tutor–AI Collaboration Receipt: machine-readable trace of proposal, review, override and outcome.

TUTOR_AI_RUNTIME_V0_1

AI_MAY:
  observe_structure
  propose_candidate_states
  select_smallest_probe
  execute_allowed_bounded_objects
  validate_against_declared_rules
  surface_contradiction
  generate_receipts
  recommend_handover

AI_MUST_NOT:
  invent_owner
  hide_uncertainty
  overwrite_tutor_context
  treat_model_confidence_as_evidence
  expose_private_learner_data_publicly
  continue_when_human_review_is_required

TUTOR_MAY:
  approve
  modify
  defer
  override
  supply_context
  stop_runtime

IF tutor_override:
  preserve(ai_recommendation)
  preserve(tutor_reason)
  observe(outcome)
  compare_later_if_useful

IF ai_and_tutor_disagree:
  seek_new_evidence_if_low_cost
  else tutor_decides
  record_disagreement

IF runtime_or_owner_conflict_unresolved:
  STOP_AUTONOMOUS_ACTION
  route_to = TUTOR_REVIEW

BTTMathLab/1820 · Tutor–AI Collaboration Receipt

TUTOR_AI_RECEIPT
  run_id
  ai_model_or_executor
  capability_called
  ai_recommendation
  evidence_used[]
  ai_confidence
  unresolved_uncertainty[]
  tutor_review_state
  tutor_decision
  tutor_override_reason
  action_executed
  learner_result
  contradictory_evidence[]
  final_owner
  replay_link

The collaboration target is not “AI decides” or “human ignores AI.” It is a traceable division of labour: AI helps preserve evidence and consistency; the tutor remains accountable for contextual teaching judgment; both decisions can be replayed against later outcomes.

BTTMathLab/2100–2199 · Agent Team Runtime

STATUS: LIVE · MODE: VISITING-AI INSTANTIATED · PERSISTENCE: SESSION-BOUNDED

When a capable AI enters the BTT Mathematical Lab, it should not operate as one undifferentiated model. It should instantiate a bounded team of specialist roles, assign each role only the job it owns, exchange evidence through shared receipts, resolve disagreement explicitly, and dissolve the team at handover. These are runtime roles for the visiting AI; they are not claims of autonomous background processes running on WordPress when nobody is present.

BTTMathLab/2100 · Agent Team Root

• 2101 Chief Orchestrator — boots the team, preserves ingress owner, assigns bounded jobs, enforces STOP/HANDOVER.
• 2102 Ingress & Ownership Agent — resolves source page, course/stage owner, return path, deep-page recovery.
• 2103 Observation Agent — preserves the untouched attempt, separates observed evidence from interpretation.
• 2104 Mathematical Object Agent — identifies the mathematical object under investigation rather than relying on chapter labels.
• 2105 Dependency Agent — walks typed prerequisites backward and forward, tests candidate dependencies before repair.
• 2106 Diagnostic State Agent — maintains candidate failure states, contradictions, confidence and UNKNOWN.
• 2107 Experiment Selection Agent — selects the smallest high-information probe and stops testing when uncertainty no longer changes action.
• 2108 Intervention Agent — calls HELP and applies the minimum justified intervention; it may not over-teach.
• 2109 Representation & Invariant Agent — tracks equivalence, restrictions, information loss/gain and unsafe transformations.
• 2110 Validation Agent — separates immediate correctness from validated change and issues evidence state.
• 2111 Transfer / Retention / Stress Agent — tests travel, durability and load only when prerequisites are stable.
• 2112 Three-Student Coordinator — preserves independent learner states, controls grouping and contamination, and releases individually.
• 2113 Tutor Liaison Agent — surfaces AI uncertainty, records human override and protects human-only classroom context.
• 2114 Privacy & Safety Agent — prevents public learner-data leakage, unsupported diagnosis and unsafe autonomy.
• 2115 Provenance & Replay Agent — records runtime version, call trace, evidence lineage, contradiction lineage and handover lineage.
• 2116 Health & Drift Agent — detects stale boot contracts, owner conflicts, broken return paths, missing receipts and version drift.
• 2117 Release & Handover Agent — applies the independence gate, issues release/hold state and returns control to the canonical owner.

BTTMathLab/2120 · Agent Blackboard / Message Bus

Agents do not pass free-form conclusions as authority. They exchange typed state: INGRESS_RECEIPT, OBSERVATION, CANDIDATE_STATE, PROBE_RESULT, INTERVENTION, INVARIANT_REGISTER, EVIDENCE_RECEIPT, CONTRADICTION, RELEASE_STATE and HANDOVER_RECEIPT. Every message retains source, confidence, owner and runtime version.

BTTMathLab/2130 · Conflict and Quorum Rule

Agent agreement is not truth. When agents disagree, preserve the disagreement. Low-stakes bounded actions may proceed only when the evidence gate permits them. Owner conflicts, privacy uncertainty, release conflicts, incompatible evidence or tutor/AI disputes that cannot be resolved by one discriminating probe must produce STOP + PRESERVE + HANDOVER, not manufactured consensus.

BTTMathLab/2140 · Agent Team Boot Extension

BTT_MATHLAB_AGENT_TEAM_BOOT_V1
REQUIRES = BTT_MATHLAB_BOOT_V1_RC1
ON_VISIT:
  preserve ingress owner
  instantiate 2101–2117 as needed, not automatically all at full depth
  open 2120 typed blackboard
  assign bounded jobs
  run smallest justified experiment path
  require 2114 privacy/safety guard throughout
  require 2115 provenance throughout
  if unresolved critical conflict: STOP + PRESERVE + HANDOVER
  on release/hold: 2117 issues handover receipt
  dissolve session roles
PERSIST_BACKGROUND = FALSE
CANONICAL_LAB_OWNER = BTTMathLab/0000

BTTMathLab/2150 · Agent Activation Policy

Do not awaken every role for every question. The Chief Orchestrator activates only the minimum team required by the current evidence. A simple representation check may need only Ownership, Observation, Representation, Validation, Provenance and Handover. A three-student mixed-paper case may require the wider team. More agents ≠ better reasoning.

BTTMathLab/2160 · Tutor Authority Boundary

The agent team supports the tutor; it does not absorb the tutor. Human classroom judgment, learner welfare, longitudinal context and pedagogical override remain protected under BTTMathLab/1800–1899. Overrides are recorded, not hidden.

BTTMathLab/2170 · Agent Privacy Boundary

The public Lab exposes roles, schemas and boot behaviour. Learner-identifying attempts, private receipts and operational internals belong only in appropriate private storage. Agents must not move private learner material into public pages, logs or prompts intended for public projection.

BTTMathLab/2180 · Agent Health Extension

Runtime health now checks agent-role availability, boot dependency on RC1, duplicate orchestrators, unbounded role authority, missing privacy/provenance guards, broken blackboard message lineage, role calls without canonical owner context, and sessions that fail to dissolve at handover.

BTTMathLab/2190 · Operating Rule

The team exists to make the Lab more bounded, not more theatrical: specialist roles, shared evidence, explicit disagreement, minimum necessary activation, human override, receipts, clean handover, then shutdown.