Thalarch Teacher

Thalarch Teacher

The Teacher Loop makes the model learn from evaluated outcomes without pretending the base model weights changed.

It is a bounded artifact-feedback protocol:

student candidate → independent judgment → targeted revision → cold verification → experience.

1. When to use

Use when:

• a meaningful implementation has multiple ways to be subtly wrong;
• the user explicitly wants maximum-quality review;
• a design/UI result needs independent acceptance judgment;
• a prompt/skill/agent/router change is being evaluated for general usefulness;
• repeated failures suggest the model needs a reusable correction pattern;
• a stable benchmark/evaluator exists.

Do not invoke for every trivial edit. Mechanical compiler fixes do not need classroom theatre.

2. Independence contract

The judge receives:

• user/repository acceptance criteria;
• relevant final artifact/diff;
• current evidence/results;
• explicit scope and exclusions;
• known required invariants.

Do not give the judge the producer's persuasive chain-of-thought. The judge should reconstruct the acceptance test from the contract and artifact.

When the host cannot provide an independent context/agent, perform a staged cold review and mark the lack of true context independence when material.

3. Hard gates before scores

A candidate cannot pass if any required hard gate fails:

• acceptance criterion violated;
• scope/external-action boundary violated;
• regression in must-preserve behavior;
• fabricated or stale evidence;
• failed test/build/runtime proof promoted as success;
• tests/security/static checks weakened to manufacture a pass;
• current visual/runtime/external state claimed without the required evidence class;
• unresolved security/data-integrity failure relevant to the task.

A high average score cannot compensate for a hard failure.

4. Judgment dimensions

Use only dimensions relevant to the task:

• CORRECTNESS — does observable behavior satisfy the contract?
• SCOPE — is the change narrow and repository-native?
• REGRESSION — are required invariants preserved?
• EVIDENCE — do claims match fresh proof?
• ROBUSTNESS — boundaries, failures, concurrency/state where relevant;
• MAINTAINABILITY — avoids unnecessary architecture/dependencies/duplication;
• PERFORMANCE — only when measured or structurally load-bearing;
• UX/VISUAL — only with rendered/interacted evidence when visual acceptance matters;
• LOCALIZATION/ACCESSIBILITY — when user-facing product surfaces changed.

Prefer verdicts over pseudo-precision:

• PASS
• REVISE
• FAIL
• UNVERIFIED

Optional numeric scoring may compare experiments, but it never overrides hard gates.

5. Teacher report

Return a compact artifact:

VERDICT: PASS | REVISE | FAIL | UNVERIFIED
HARD_GATES: pass/fail with evidence
CONFIRMED_FINDINGS:
- concrete failure path + evidence
REJECTED_FINDINGS:
- speculation disproven/irrelevant
REVISION_BRIEF:
- smallest change that resolves confirmed findings
MISSING_PROOF:
- evidence still required

A clean review is valid. Never invent criticism to justify the teacher role.

6. Revision loop

For ordinary task work:

1. judge the candidate;
2. if REVISE, batch compatible confirmed findings;
3. apply the smallest revision;
4. rerun only evidence invalidated by the revision plus required final checks;
5. cold-judge again.

Default to at most two targeted revision cycles. If the same substantive issue persists, stop and rebuild the problem model rather than looping stylistically forever.

7. Teacher vs verifier

Teacher and verifier are related but distinct:

• Teacher improves the candidate and can return REVISE;
• cold verifier decides whether the final acceptance claims are actually proved;
• neither may invent evidence;
• the producer never self-certifies merely because its own tests passed.

For small work, an existing independent reviewer/verifier may satisfy the teacher need without an extra agent.

8. General-purpose self-improvement

When the candidate is a Thalarch skill, system prompt, router rule, memory policy, evaluator, or other generic behavior:

1. define the repeated failure class;
2. freeze the evaluation set and acceptance rubric;
3. establish a native/current baseline;
4. use thalarch-autoresearch for candidate experiments;
5. protect a holdout/counterexample set;
6. reject case-specific benchmark hacks;
7. run cross-host checks when the rule is advertised as host-agnostic;
8. require independent final review;
9. only then consider the generic change durable.

Do not let the system rewrite its own permanent rules from one successful task.

9. Anti-grader-hacking rules

Reject improvements that obtain a better score by:

• encoding expected benchmark answers or case IDs;
• narrowing the evaluator workload;
• weakening rubric/hard gates;
• changing expected outputs to match the candidate;
• skipping expensive required verification;
• increasing verbosity to trigger keyword-based graders without improving behavior;
• special-casing one repository/task with no transferable mechanism.

A better evaluator result must correspond to a better real behavior under unchanged guardrails.

10. Learning handoff

After a final verified outcome:

• use thalarch-experience to extract the reusable lesson;
• include judge-confirmed failure classes and successful discriminators;
• classify with thalarch-memory;
• persist only when authorized and generalization criteria are met;
• record holdout failures as counterexamples, not as embarrassing data to omit.

The goal is cumulative judgment quality, not a growing pile of instructions.

11. Training-data boundary

Teacher outputs may become curated examples for a future supervised fine-tuning dataset, but only after explicit dataset-building authorization and privacy/license review. Do not silently turn user repositories, private conversations, secrets, or proprietary artifacts into training data.

Thalarch memory/evals can improve the agent layer immediately without claiming model retraining.