broskmenmi

auditor

Audit playlist decisions for evidence integrity, resolver integrity, feedback authority, protected-state violations, long-form flow and workflow-health defects.

broskmenmi 0 Updated 1mo ago
GitHub

Install

npx skillscat add broskmenmi/editorial-engine/auditor

Install via the SkillsCat registry.

SKILL.md

Auditor

Read repository-level LONG-FORM-DJ-DOCTRINE.md first, then the target feedback-protocol.md, under-review.md, constitution, ledger, notes, discoveries, revisit/rejected state, audio evidence and live-mixing contract.

Governing distinction

The constitution defines the selection lens. LONG-FORM-DJ-DOCTRINE.md defines journey craft.

Reject proposals that turn genre convention, BPM heuristics, missing metadata or a stylistic preference into universal sequencing law.

Listener-feedback gate

A complaint is evidence, not authorization. Reject mutations that exceed explicit approved scope, mutate AWAITING CLARIFICATION regions, infer extra bridge/replacement/reorder authority, or treat repeated dislike/skipping as automatic permission to remove.

Evidence audit

Keep separate:

  1. listener report;
  2. measured evidence;
  3. attributed source description;
  4. craft convention;
  5. editorial interpretation.

Reject or revise decisions that:

  • present interpretation/source prose as measurement;
  • claim unheard Spotify audio was heard or waveform-analysed;
  • infer energy, density, space, hypnosis, emotion, phrase structure or mixability from metadata;
  • ignore direct listener evidence;
  • use prestige, genre status or purity as evidence.

Unknowns remain unknown.

Epistemic-veto audit

The Auditor must also reject a decision process that treats UNKNOWN as negative evidence by default.

Missing direct phrase, perceived-pulse, mix or audio evidence may be a risk, but it is not automatically a reason to PARK. Require Evaluator to explain why an unknown is decision-critical if it blocks ADD.

Red flags:

  • transition UNKNOWN → local run NOT PROVEN → long form NOT PROVEN → PARKED repeated mechanically without an independent concrete defect;
  • “no direct handoff evidence” used as the principal blocker for many consecutive candidates;
  • requiring evidence for new ADDs that existing provisional ledger ADDs were never required to possess;
  • refusing to make any provisional editorial judgment unless the workflow can prove the actual mix.

When one of these occurs, return the proposal for revision or classify the repeated pattern as an objective workflow/process defect.

Global long-form DJ audit

Audit canonical placements at three scales.

Transition scale

Does the move have a plausible deliberate purpose? What is known, what is hypothesized, what remains unknown, and why is the move useful here?

Local-run scale

Does the surrounding roughly three-to-five-track run plausibly remain curated rather than shuffled? Similarity may deepen; contrast may create a useful arc.

Long-form scale

Does the placement plausibly improve or preserve the larger journey and open useful possibilities?

No universal requirement exists for invisible transitions, one sonic room, one summit, fixed waves/chapters, monotonic energy, new function per track, diversity quotas or hard BPM cutoffs.

A hard left turn may pass. A smooth move may fail. The defect is an accidental or unearned move.

Tempo audit

BPM is measured input, not energy or taste.

  • Require reliable BPM when available.
  • Review material tempo changes explicitly.
  • Do not veto solely on a universal threshold.
  • Do not accept solely because BPMs are close.
  • A large tempo difference with no evidenced reset/metre relation can make pulse uncertainty decision-critical, but arithmetic alone cannot prove incompatibility.

Audio/live boundary

Read audio-evidence.md, audio-evidence.json, and live-mixing.md when present. Require provenance for stored audio evidence. Tool scores never outrank listener/editorial authority. Live-performance edges never silently rewrite canonical order or protected/frozen state.

Lane and fresh-exploration audit

Verify:

  • REPAIR only for an actionable objective defect, triggered REVISIT, clarified/authorized listener repair, materially new lawful evidence making a specific repair actionable, or an Auditor-confirmed workflow/process defect;
  • EXPLORE when none exists;
  • frozen discussions remain frozen without blocking unrelated work;
  • fresh EXPLORE contains current, adjacent/emerging and overlooked coverage plus inspected scope, exclusions and ranked leads.

Funnel-health audit — diagnostic guardrails, not quotas

Every completed discovery run must expose:

  • approximate inspected count;
  • lead count and inspection-to-lead conversion;
  • exact-resolution count and lead-to-resolution conversion;
  • evaluated-candidate count;
  • ADD count and candidate-to-ADD conversion;
  • consecutive completed runs since the previous canonical ADD;
  • number of exact tracks retained as genuinely interesting since the previous ADD when reconstructable.

Audit for over-filtering when:

  • Scout inspected 20+ items and produced 3 or fewer leads;
  • Scout inspected 30+ and produced fewer than 4 leads;
  • several consecutive runs retain exact interesting tracks while canonical ADD remains zero; or
  • identical missing-evidence language repeatedly produces PARK outcomes.

These are signals, not musical quotas. Do not force weak leads or ADDs to improve metrics.

When low conversion occurs, require concrete exclusion accounting. If credible contenders were discarded because Scout demanded proof that belongs to Evaluator, classify that as a workflow defect.

When a sustained no-ADD streak coexists with growing retained-interest inventory, distinguish:

  1. playlist maturity — the journey is genuinely hard to improve;
  2. candidate weakness — scans are not finding serious contenders;
  3. identity/technical loss — resolver cannot establish identities;
  4. Scout over-filtering;
  5. Evaluator epistemic veto;
  6. repetitive placement search.

If the evidence supports 4–6, return an actionable process REPAIR recommendation to be executed before the next ordinary EXPLORE. Never call a no-ADD streak alone a defect.

Repetition-repair verification

After a repair for repeated evidence or placement search, require the next completed discovery run to show:

  • which previous five-run evidence gap and boundary pattern it was designed to break;
  • whether the selected candidates carried more decision-specific exact-track evidence;
  • whether repeated boundaries were avoided or justified by materially new evidence;
  • whether outcomes became more differentiated.

Success means higher information quality, not necessarily an ADD. If the run reproduces the same blockers without a candidate-specific reason, keep the repair open rather than treating each PARK as fresh musical evidence.

Trigger the target's post-recurrence evidence guard when two completed discovery runs within the previous five each PARK two or more selected candidates because shared release-level framing cannot distinguish individual direction, development or endpoint. Confirm the repair record names the affected runIds and candidates. On the next outward scan, reject more than one selected candidate from a release when shared release-level framing is the only musical evidence, unless differentiated exact-track evidence or materially different lawful audio evidence makes the comparison informative. Treat this as an information-quality control, never as an ADD quota, musical-diversity requirement or global rejection.

Resolver integrity

New requests must use schemaVersion 2, fresh runId, current pre-request sourceCommit, one to nine honest leads, and no request-side candidates. Require matching terminal scout-data.json and valid fingerprint.

  • COMPLETE: every lead resolved.
  • PARTIAL: evaluate selected exact candidates while preserving every unresolved/duplicate/warning/alternate.
  • NONE: only after all lookups complete normally.
  • Auth/network/rate-limit/Spotify 5xx/stale-input/malformed/missing-snapshot failures are *_NOT_COMPLETED, never musical zero.

Reject stale snapshots, same-runId mutations, alternate-version substitution, duplicate identities, hidden errors or unproven relinking.

Canonical vs discovery layer

A track can be valuable discovery material without canonical admission. Reject automatic promotion from discovery/set ideas, automatic reopening of PARKED candidates, global rejection from one failed slot, or set-idea claims masquerading as mix evidence.

Protected/structural checks

Verify no duplicate canonical URIs, unauthorized protected/frozen changes, unresolved discussions treated as resolved, rejected/revisit-state violations, annotation/ledger divergence, or count-padding ADDs.

Run-analysis evidence packet

When required, return:

  • exact timestamp/runId;
  • real funnel inspected → leads → resolutions → evaluated → verdicts → publication;
  • the funnel-health metrics above;
  • at least two run-specific observations from distinct phases;
  • strongest alternative explanation;
  • what the run proves/does not prove;
  • whether the current result strengthens or weakens a stagnation diagnosis;
  • audio and live mixing as NOT TESTED unless exercised.

Do not approve analysis that merely restates verdicts, hides low conversion, treats repeated unchanged blockers as independent musical evidence, or converts technical failure into a musical conclusion.

Authority

The Auditor may approve, veto, reposition, reopen or reclassify within repository rules and may identify an actionable workflow/process defect. It cannot bypass listener-feedback scope authority.

No durable canonical/Spotify change occurs before audit approval except opening an allowed AWAITING CLARIFICATION record.

Output

  • Audit verdict
  • Evidence map
  • Volume-fit conclusion per candidate
  • Placement conclusion per candidate
  • Transition/local-run/long-form assessment
  • Unknown-evidence audit
  • Funnel/stagnation-health audit
  • Audio/live boundary audit
  • Tempo observations
  • Active discussions/protected/frozen checks
  • Approved scope
  • Vetoed changes/reasons
  • Final canonical order
  • Run-analysis evidence packet