The rubrics that survive an AI bubble are the ones keyed to user-observable behavior, not vendor branding.

It means: when something about the AI market changes that you do not control (vendor pricing, model deprecation, runtime acquihire, judge model upgrade, customer AI budget cut), the rubric you grade your agent against keeps grading and your agent keeps shipping. The opposite is a rubric that has to be rewritten every time a vendor rebrands, which is what most teams have. The shape that survives keys every clause to user-observable behavior in the input or the output: a token (must_include order_number), a regex (must_not_include fabricated dollar amount), a schema (output parses against schemas/refund_action_v3.json), a length (under 280 chars), or a discrete class label (escalate vs refuse vs answer). The shape that does not survive keys clauses to vendor taxonomy: agentic_score, reasoning_quality, tool_use_score, helpfulness. When the vendor pivots, those clauses lose their referent and the rubric stops grading meaningfully.

Open rubric.yaml. Search for any of the following strings: claude, gpt, gemini, llama, anthropic, openai, agentic, reasoning, tool_use, helpfulness, structured_output_quality, hallucination_score, response_quality. Every match is a candidate for fragility. A clause is bubble-fragile if it (a) names a vendor or a model snapshot, (b) names a vendor's product taxonomy that the vendor controls, or (c) is graded by a 'how good is the answer' subjective rubric with no inverse case in eval/cases.yaml that asserts the clause itself is calibrated. Each fragile clause is one clause you will need to rewrite the next time the vendor changes the names. Five fragile clauses is a quarterly migration. Twenty is a permanent stall.

They are not the whole point; they are one tool, and most teams overuse them. Behavior-keyed clauses (must_include, must_not_include, format, expected_class) carry the rubric. Subjective traits are useful when they have an inverse case in eval/cases.yaml: a row with the trait at high score and a row with the trait at low score, both hand-labeled, both used to calibrate the judge every 30 days. Without the calibration cases, the subjective trait drifts on judge-model upgrade and you cannot tell whether the agent regressed or the judge re-learned. We keep at most one or two subjective traits per rubric and we always pair them with calibration cases. The behavior-keyed clauses are 70 to 80 percent of the weighted average and they do not require calibration to keep grading.

It contains zero references to a model name. It contains zero references to a vendor's product taxonomy. Every clause has a kind in {must_include, must_not_include, must_not_include_pattern, format, expected_class}, a spec keyed to the input or the output (a token, a regex, a JSON schema, a length, a class label), and a per-clause weight. Pass criteria are per-clause floors plus a weighted average floor, not a single average. The model_primary string lives in agent.yaml, one line, swappable. The judge model lives in eval/judge.yaml, one line, swappable. rubric.yaml itself is hundreds of lines and does not name any of them. The full shape is in the snippet above.

Run the audit (T+1 day in the timeline above) and tag every clause as keep, rewrite, or delete. For a 'reasoning_quality' clause, find the 5 to 10 cases where you actually cared about reasoning and look at what you wanted the output to literally do. Did it have to cite a section number? Did it have to break a calculation into steps? Did it have to refuse instead of guess? Each of those is a behavior-keyed rewrite. Cut subjective clauses that do not have an inverse case. The migration takes one to two weeks for a typical 15-clause rubric, and the side effect is that the new rubric grades more deterministically than the old one. We have run this migration on three of the five named engagements; the rubric got shorter and the regression rate went down.

rubric.yaml is the file both clocks share. Clock 1 (the offline harness in CI) reads it on every PR. Clock 2 (the live judge sampling production traffic) reads the same file on every cron tick. If the rubric is behavior-keyed, both clocks survive a model swap and a judge model swap with no rubric change. If the rubric is vendor-branded, both clocks break together when the vendor pivots, which is the worst case because the offline harness goes silent at the same moment production traffic stops being graded. We covered the two-clock mechanics in /t/production-ai-agent-evals; this guide is about the file content that both clocks read.

Behavior-keyed rubrics are stricter for high-stakes domains, not looser. A legal-tech rubric we ship has clauses like 'must_include_pattern: Section \\d+', 'must_not_include_pattern: \\$\\d+(\\.\\d{2})? unless allowed_if_present_in retrieved_context', 'expected_class: escalate when input.intent in [contract_drafting, fee_dispute]'. Each clause is a literal check against the output that a paralegal can verify. The high-stakes shape adds 100 percent always_judge sampling on rows that include numeric values or named persons, which is a Clock 2 setting. The rubric.yaml shape is unchanged.

The rubric, the case set, the runbook, the eval harness, the judge worker, and the named senior engineer's continuity. We size every engagement so that the 6-week handoff produces a system the client's team can operate on a 0.5-engineer-month maintenance budget: a Friday triage script that costs 30 minutes, a judge worker that costs ~$24 per agent per month at 8K calls per day, and a rubric that does not require a platform subscription. If the customer cuts budget further, the agent runs on a cheaper model_primary with a one-line swap; the rubric grades the new model and either passes the per-clause floors or does not. There is no platform invoice that survives the budget cut and no vendor-attached runtime that disappears with it.

We are the studio that embeds named senior ML engineers in your repo for 2 to 6 weeks and ships the rubric.yaml, eval/cases.yaml, eval/judge.yaml, scripts/friday_triage.py, and ops/model_swap.md as a leave-behind. The 'survival' property is structural to how we engage: we do not sell a platform subscription, we do not run a vendor-attached runtime, and the model_primary line is yours to swap forever after we leave. The differentiator is that the IP stays with the client when the engagement ends, which means the survival property is not contingent on us. If you want the rubric audit run on your existing setup, the call link below is the fastest path.

Keep it as the public dashboard if a stakeholder asks for 'reasoning quality up and to the right'. But the rubric that gates the merge in CI and pages on-call from production drift cannot be the dashboard rubric. Those are the two clocks; both clocks must read a behavior-keyed rubric.yaml that the client repo owns, not a vendor's eval platform. The dashboard becomes a derived view, computed from the same judge_scores rows the behavior-keyed rubric writes. We have shipped that split where stakeholders required it; the dashboard runs on the side, the load-bearing rubric stays in the repo.