Regulating maintainability

Of the three things a harness regulates, maintainability is the one the industry has actually solved, because it is the one that looks like ordinary software quality. Does the output parse. Is every required field there. Does it follow the house style. Is it the length it should be.

Every one of those can be checked deterministically, for free, on every single output. That is the whole argument for doing it first: a maintainability sensor never hallucinates, never costs a model call, and never disagrees with itself between runs.

• Schema validation on anything structured. A reply that does not parse is a failure regardless of how sensible it reads.
• Required-field checks. Missing a field is a different failure from a wrong one, and conflating them hides which you have.
• Forbidden-phrase gates. A regex for promises, dates, amounts — whatever your domain must never say unprompted.
• Length and format bounds. Two sentences means two sentences; a sensor can count.

These are the evals course's first graders — schema_valid, exact_match — seen from the harness side. The evals course built them to measure; the harness runs them to govern. Same code, different job: a grader reports a number at the end, a sensor rejects an output before it ships.

// A grader, from the evals course: measures.
schemaValid.grade(output, expected)  // -> { score: 0, note: "missing field: reply" }

// The same check as a sensor in the harness: governs.
if (!schemaValid.grade(output, expected).passed) {
  return retry("The reply must include a category, an urgency and a reply.");
}