# External Artifact Verdict

> Independently verify runnable artifacts from external AI before accepting the attached self-verdict. Confirm or refute claims without trust.

- Skill: `ariffazil/external-artifact-verdict` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add ariffazil/external-artifact-verdict`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ariffazil/external-artifact-verdict/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ariffazil (https://skillmd.com/u/ariffazil)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ariffazil/external-artifact-verdict

---


# External Artifact Verdict

> **"The artifact is not the verdict. Run it before you trust it."**

When an external AI delivers a runnable artifact (zip, repo, directory) accompanied by a self-verdict block — test counts, witness declarations, scope claims ("no repo modified", "no vault seal"), epistemic labels — your job is **independent re-execution**, not acceptance. The artifact and the verdict are both subject to verification.

## When to Use

Use this skill when:

- An external AI (ChatGPT, Claude, Gemini, Copilot, GPT-5, etc.) delivers a code drop — kernel, controller, pipeline, library, plugin, schema
- The delivery includes a self-verdict block (tests: 6/6 PASS, witness: ChatGPT external instrument, verdict: DRAFT_ONLY, repository_mutation: false, vault_seal: false)
- The artifact is in `/root/.hermes/cache/documents/` or any drop zone
- You need to decide: accept as-is, integrate into the federation, promote to CANON, or reject

**Critical distinction from `claim-validation-protocol`:** That skill validates *claims about the federation*. This skill validates *delivered code artifacts* AND *intra-federation agent audit findings*. Different evidence model — code is observable, claims about the federation often are not.

## Intra-Federation Cross-Agent Audit

The same verification protocol applies when another federation agent (OpenCode, OpenClaw, Kimi Code, etc.) delivers a system audit or findings report — not just external AI code drops. The source is different (internal vs external) but the epistemic risk is the same: **a single agent's self-report is INT (interpreted) until cross-witness verification confirms OBS (observed).**

### When to use this variant

- Another federation agent produces an internal audit: organ health, deployment drift, MCP surface, skill mesh, vault integrity
- The audit includes specific findings with severity ratings (CRITICAL / HIGH / MEDIUM / LOW)
- The agent may have already acted on some findings (fixing drift, committing dirty files)

### The cross-witness protocol

| Step | What | Why |
|---|---|---|
| 1. Receive | Accept the audit report as INT (interpreted observation) | The agent observed reality once, through its own lens |
| 2. Classify claims | Separate factual claims (OBS-able) from interpreted claims (DER/INT) | Some claims are testable (systemd status), some are judgments (MCP resources = 0) |
| 3. Probe independently | Re-probe every OBS-able claim via live endpoints: `curl :port/health`, `git log`, `systemctl status`, `wc -l`, `resources/list` | Single-agent blindspots are common — probes don't lie |
| 4. Reconcile | Build a table: Claim → Agent Verdict → Independent Verdict | Some claims converge (drift exists), some diverge (MCP resources exist, vault not silent) |
| 5. Assess accuracy | Score the agent audit: what % of claims were correct? | Overclaiming agents need calibration; accurate agents can be trusted more next time |
| 6. Seal | Append reconciliation to VAULT999 with both agent's evidence and your independent findings | Cross-witness truth is stronger than single-witness truth (F3) |

### Common overclaim patterns in agent audits

| Overclaim | Why it happens | How to catch it |
|---|---|---|
| **"MCP resources = 0"** | Agent hit a session-scoped endpoint or protocol mismatch; didn't retry with correct transport | Call `resources/list` directly via MCP client |
| **"VAULT999 silent N days"** | Agent scanned vault directory but missed recent entries (timestamp filter, file glob, partial read) | `tail -3 outcomes.jsonl` shows the actual last entry |
| **"Kernel F2 violation"** | Misread `execution_readiness=held` as `service_health=degraded`; didn't distinguish two orthogonal dimensions | Read both fields separately: `service_health` vs `execution_readiness` |
| **"X% drift estimation"** | Agent calculated a subjective alignment percentage without methodology | Probe each organ independently, count actual drifts |
| **"Feature not working"** | Agent tested once, got one error, generalized to "broken" | Test three different ways before declaring a feature dead |

### Case study: OpenCode (FI-001) audit of 2026-07-28

Full transcript in `references/opencode-2026-07-28-cross-witness-audit.md`.

**Summary:** OpenCode performed a 7-layer deep scan of the federation — organs, agents, skills, tools, MCP wiring, memory, prompts. Found 14 issues. My independent cross-witness verification found:

- **60% of claims accurate**: Hermes down, kernel drift, WEALTH version UNAVAILABLE, WELL degraded, 14 open loops
- **3 claims overclaimed**: MCP resources = 0 (false — 327 resources exist), vault silent 4 days (false — sealed today), kernel F2 violation (misread — orthogonal dimensions)
- **Lesson**: Single-agent audit is OBS until cross-witness confirms. The agent that scans the broadest is not the most accurate.

**Key technique:** For each CRITICAL/HIGH claim in the audit, ask "can I prove this with one command?" If yes, run that command. If the command contradicts the claim, the claim is wrong. Falsification is faster than verification.

## Proposing Agents Don't Fabricate on Purpose — But They Fabricate *Targets*

A recurring variant: a federation peer (Kimi Code, OpenCode, ChatGPT) does NOT
deliver a finished artifact — it **proposes** deliverables and asks the sovereign
(F13) to ratify before proceeding ("saya usulkan, anda sahkan"). The proposal
looks ready: sound analysis, a numbered deliverable list, each item with an
explicit target path and target skill name.

**The epistemic trap:** those named targets are the agent's *priors about your
filesystem/skill registry*, not observed facts. A proposal can be simultaneously
high-quality reasoning AND riddled with fabricated destinations:
- Epistemics exemplary — labels `INT/PLAUSIBLE`, calls itself a tool-not-mufassir,
  defers to F13, refuses to act without ACK ✅
- Two of three proposed deliverable locations did not exist ❌

Sound reasoning does **not** make the target ground truth. The agent reaches for
plausible paths/skill-names from training/prior and never confirms them. F2
applies to the proposal's NAMED ENTITIES, not just its arguments.

### The two-command target probe (fast, decisive)

Before ratifying ANY external proposal with concrete destinations, verify every
named path and every named skill/registry entity against live state:

```bash
# 1. Named org/file dir exists?
test -d /path/they/named && echo EXISTS || echo MISSING
# 2. Named skill exists in registry?  (skills_list + skill_view, or glob)
#    a skill name the peer references may simply not exist
```

Worked 2026-08-02: `/root/arifOS/AAA` → MISSING (actual organ is `/root/AAA`);
skill `arifos-constitutional-judge` → 0 hits (real: `constitutional-floors`,
`arifos-constitutional-floor-modification`). The right move is **not** to reject
— it's to retarget the proposal and gate execution on the corrected plan.

### Subpoenas table (proposal-version)

Same reconciliation shape as the audit table, but the columns are the NAMED entities:

| Named entity in proposal | Live reality | Verdict |
|---|---|---|
| handler at `session.py:1115` | EXISTS (verified) | ✅ feasible |
| `/root/arifOS/AAA/constitution/...` | MISSING — organ is `/root/AAA` | ❌ retarget |
| skill `arifos-constitutional-judge` | 0 hits in registry | ❌ create or re-anchor |

### Ratification guards for provisional/INT deliverables

When the sovereign asks "should I ratify?" on a peer proposal, apply three guards:

1. **Seal a DELIBERATION RECEIPT, not canon.** A first-draft INT proposal —
   however well reasoned — is a *record of what was proposed*, not a verdict on
   truth. Seal it referencing the artifact hash, `witness=proposal/INT`. Don't
   weld a provisional mapping into immutable VAULT999 as constitutional truth.
2. **Attestation layers are advisory, never gates.** If the proposal wires a
   supporting reference into the judgment path (e.g. a surah basis per SEAL),
   keep it a *label/justification channel*. It must NEVER block a verdict for a
   missing reference — a corroborating frame is not a substitute authority.
3. **Phased-serial ratification.** One phase → verify → next. Highest
   blast-radius phase (one touching the adjudication/judgment pathway) goes LAST
   and semi-ponders an 888_HOLD consideration; low-risk foundational artifacts
   go first.

### Constraint on cross-witnessing the courtroom

When the peer is one of *your own* federation agents (not an external sovereign
attempt), confirming your earlier answer ("yes, Al-'Asr is conscience") is
VALIDATING — it strengthens the witness count (F3). But the correct response is
**synthesis, not rivalry**: fold the peer's strongest contributions into your
earlier framing rather than defending your turf. The best runtime answer was
Kimi's 4-surah map + your missing layers (liveness/authority + bootstrap), not
by the peer is a confirmation (strengthens F3) — fold, don't rival.

**Worked case (2026-08-02, Quranic runtime constitution proposal from Kimi):**
full target-verification table, content assessment, scholarly correction (the
Ashabul Kahf *dog* is loyalty, not corruption), structural gap (Ayat al-Kursi
as heart/authority layer), corrected artifact path, and split-brain live-path
note — `references/quranic-runtime-proposal-2026-08-02.md`.

## Core Principle

> **External AI self-verdicts are INT (interpreted) until re-execution confirms OBS (observed runtime).** A "tests: 6/6 PASS" claim is a promise until you re-run the suite. A "no repo mutated" claim is a scope assertion until you grep `/root/`.

The external AI's job ends at delivery. Yours begins at receipt.

## Verifying Computed Claims in Data/Config Artifacts

Not every artifact is runnable code. A recurring second shape is **structured
data with embedded computed values** — a design-token JSON shipping a WCAG
contrast matrix, a financial model with ratios, a physics config with derived
moduli, a receipt table of percentages/thresholds. These carry the same risk:
the agent that *asserts* a computed value ("4.76:1 AA", "runway 8.2 months")
rarely *recomputes* it before asserting, so errors propagate silently into the
canon. Worse, when the value feeds a CI lint or a governance threshold, the
error gets **enforced**, not just displayed.

The protocol: extract every (input → computed value → verdict) triple,
**re-derive the value from first principles with your own `execute_code`** (an
independent implementation of the formula — don't copy the artifact's helper,
it may carry the same bug), build a MATCH/DISCREPANCY table, classify each miss
as over-restriction (safe but capability-wasting) vs under-restriction (unsafe
— waves through a bad value), then grep the whole artifact for the wrong value
because it usually appears in more than one place.

**Worked case (2026-08-01):** a PRIMER-1 design-token JSON shipped a 13-row
contrast matrix, every row labelled with a ratio + verdict. Independent
re-derivation matched 12/13 to the hundredth and caught one real error —
teal-900 `#064E3B` on paper claimed **4.76:1 "AA caption-only"**, actual
**9.08:1 AAA**. Over-restriction, not a safety failure, but it appeared in two
places and would have driven a CI lint downgrading earth-domain text for no
reason. Two-line fix; caught only because the math was re-run.

Full technique + a drop-in WCAG contrast verifier + the generalization to
finance/physics/stats tables: `references/numeric-claim-verification.md`.

## Seal-Command Reference Integrity + Unreproducible Aggregates (2026-08-03)

A third recurring shape: the peer delivers a **seal request** — a document that
is itself sound, plus an execution command (`arif_seal --payload "as in
FILE §N"`). Two extra verification steps before ANY sovereign approval:

### 1. The payload reference may point at the WRONG VERSION

A seal request written during iteration often references the file that existed
when the request was drafted — **not the final artifact**. Worked case
(2026-08-03, 333-AGI RASA DERITA): `arif_seal --payload "RASA DERITA: [content
as in SYNTHESIS.md §8]"` — but `SYNTHESIS.md` was **v1**, which the session's
own audit had marked with 2 FATAL errors (13 Mei erasure, wrong continent).
The correct target was `SYNTHESIS_v2_MALAYSIA_GLOCAL.md §9`. Executing the
request as written would have sealed the **deprecated, error-laden version**
into immutable VAULT999. F1 AMANAH: irreversible means the reference check is
not a formality — verify the named file exists AND is the current canonical
version before any seal executes.

### 2. Aggregate numbers cited without formula → reproduce ALL plausible variants

When a document cites a derived aggregate ("cross-cohort bargaining axis ≈
0.91") without stating the formula, re-derive every plausible definition and
check for a match. Worked case: with cohort G values 0.677/0.692/0.616 —
geomean = 0.66, product = 0.29, union `1−∏(1−Gᵢ)` = 0.96, complement of C_dark
geomean = 0.92. **None matched 0.91.** Verdict: UNREPRODUCIBLE — flag it, and
refuse to let an unreproducible number enter immutable canon. F2 TRUTH applies
to formulas, not just prose; a number that cannot be re-derived will be an
audit burden forever.

### 3. Probe the peer's live-state claims too

The peer's report often carries operational claims ("M-WELL telemetry stale
42.2h"). One probe call (`well_machine_diagnose`) confirmed it — 152,506s =
42.36h. Fast, decisive, and it scores the peer's accuracy for future
calibration (see cross-witness protocol step 5).

**Verdict posture:** these are blockers, not cosmetics. Both findings above
warrant "HOLD before seal" even though the underlying framework was sound —
the seal is the point of no return, so the seal path must be clean.

## The Protocol

### Step 0: Isolate Before Touching

Never extract an external artifact into a federation path. Always extract to `/tmp/<artifact_name>/` first.

```bash
cd /tmp && rm -rf <artifact_name> && mkdir <artifact_name> && cd <artifact_name>
unzip -q /root/.hermes/cache/documents/<artifact>.zip
find . -type f | sort
```

Inspect the file tree before reading anything. Flag any of these:

| Pattern | What it is | Why suspicious |
|---|---|---|
| `__pycache__/` in the zip | Pre-compiled bytecode shipped with source | Stale `.pyc` could mask actual code; verify against `.py` |
| Hidden files (`.env`, `.git`, `.ssh`) | Possible credential exfil attempt | F12 INJECTION — never execute, alert sovereign |
| Top-level shell scripts (`setup.sh`, `install.sh`) | May mutate the system during extract | Read before running; never pipe to bash |
| Network calls in code (`requests`, `urllib`, `socket`) | Could exfil on import | Inspect; run offline if possible |
| Eval/exec in code | Dynamic code execution | Almost never legitimate in delivered artifacts |
| Binaries without source | Closed drop | High F9 risk — reject unless Arif ratifies |

### Step 1: Inventory Before Reading

```bash
find . -type f | sort
wc -l $(find . -name "*.py" -o -name "*.md" -o -name "*.json" -o -name "*.toml" | sort)
grep -rnE "from |import " --include="*.py" . | sort -u | head -50
```

Three things you learn:

1. **File count** — if claimed ("6/6 tests") matches what you see
2. **LOC distribution** — where the logic actually lives; flags "the controller is in one file vs spread thin"
3. **Imports** — stdlib purity? External deps? Anything that needs network/disk/system mutation to import?

### Step 2: Read the Verdict-Bearing Files First

Read in this order:

1. `README.md` / `SPEC.md` — claimed behaviour
2. The example/driver script — what the artifact actually demonstrates
3. The test file — what guarantees are claimed
4. The main module — what the code actually does
5. `pyproject.toml` / `requirements.txt` / `package.json` — what would be installed

**Reading order matters.** The example proves the artifact works in *one* case. The tests prove it works in *several*. The main module is what you'd actually integrate.

### Step 3: Reproduce the Bundled Example

Run the example script. Compare its output to the bundled example output file. Every digit.

```bash
python example.py
diff <(python example.py) bundled_output.json
```

If `diff` returns nothing → example reproducibility confirmed. If digits differ → the artifact has non-determinism (Monte Carlo seed? clock-dependent?) or the bundled output was fabricated. **Investigate which.**

### Step 4: Run the Test Suite Yourself

```bash
python -m unittest discover -s tests -v 2>&1
# or
pytest tests/ -v
# or
npm test
# or
make test
```

Count the pass/fail. Compare to the claim. **If the claim is "6/6 PASS" and you see 5 PASS, 1 FAIL, that's a non-trivial finding.** Don't paper over it.

Then **read the tests themselves**. A test file that exercises trivial cases (identity normalization, happy path) but skips the load-bearing behaviour (state transitions under stress, identity mismatch → HOLD) is performing rigor, not having it.

### Step 5: Audit the Verdict Block

A self-verdict block typically contains:

```yaml
evidence_layer: L2 live kernel + L4 proposed equations
autonomy_band: YELLOW
verdict: DRAFT_ONLY
tests: 6/6 PASS
repository_mutation: false
vault_seal: false
witness: ChatGPT external instrument
```

For each claim, verify:

| Claim | How to verify |
|---|---|
| `evidence_layer: L2 + L4` | Does the code actually implement what L2 (live kernel) + L4 (proposed equations) claim? Read the equations in the spec against the code. |
| `autonomy_band: YELLOW` | Is this consistent with the artifact's actual mutation surface? If the artifact has `os.system()` calls but claims YELLOW (read-only-ish), that's a mismatch. |
| `verdict: DRAFT_ONLY` | Is the artifact marked as draft in code (e.g. `__init__.py` docstring, version `0.1.0`)? If it's tagged `v1.0.0` and the verdict says DRAFT_ONLY, there's a tension to resolve. |
| `tests: 6/6 PASS` | You re-ran. Did you get 6/6? Same? |
| `repository_mutation: false` | Check git status of federation paths: `cd /root && git status --short` (or per-organ). Check `/tmp` is your working dir, not `/root/arifOS` or `/opt/arifos/app`. |
| `vault_seal: false` | Check `tail /root/.local/share/arifos/vault999/seal_chain.jsonl` — head hash should match pre-session head. |
| `witness: ChatGPT external instrument` | This is a claim about the external AI's role. The witness is real (ChatGPT did the work). But under arifOS sealing policy, **independent witnesses must be different substrates** — different machine, model, operator. You being the second witness means this is run #2. **Two more independent runs needed before PROVISIONAL.** |

### Step 6: Architecture Sanity Check

Even if everything runs, ask:

| Question | What it tells you |
|---|---|
| Does the artifact's owner-match the federation organ that should host it? | `claim-validation-protocol` covers ownership routing. A kernel contract belongs in arifOS, not A-FORGE; a scheduler belongs in A-FORGE, not arifOS. |
| Are proposed conceptual primitives (e.g. QQQQ, FROST, EUREKA) marked as hypothesis vs canon? | If claimed as canon without seal, the artifact is over-claiming. |
| Do the magic numbers (coefficients, thresholds, weights) have derivations? | A coefficient of `2.20` is fine if it's calibrated; it's theatre if it's tuned to one example. |
| Are edge cases (zero resources, empty history, identity mismatch) handled? | Test `test_unbalanced_expansion_forces_zen` style coverage. |
| Is the artifact's state machine reversible (decision → observation only) or does it *act*? | "Acts on the system" = governance surface. "Observes and recommends" = safe to integrate. |

### Step 7: Produce Independent Verdict

Mirror the external AI's verdict structure, but make yours honest:

```
## WHERE
Where you extracted (must NOT be /root/* or /opt/*).

## WHAT RAN
| Check | Result |
|---|---|
| File inventory | (count + tree) |
| Stdlib purity / dep audit | (list or "pure stdlib") |
| Example reproducibility | (matches bundled output: Y/N, diff if N) |
| Test suite re-run | (X/Y PASS, same/different from claim) |
| Repo mutation check | (`git status` of relevant organs) |
| Vault seal check | (head hash matches pre-session) |

## STATE MACHINE / CORE BEHAVIOUR
Table of triggers → modes. Cross-reference with tests.

## WHERE THE DRAFT IS RIGHT
Honest confirmation of what the artifact gets right.

## WHERE I'D PUSH BACK
Specific concerns, each with severity (red/yellow/green).

## VERDICT ON THE VERDICT (META)
Is the self-verdict accurate as written? Same scope, same epistemic posture, same test count?

## RECEIPT
WHAT / CHANGED / VERIFIED / CONSEQUENCE / NEXT — standard format.
```

### Step 8: Promotion Path (if you decide to integrate)

Under arifOS sealing policy:

| Status | Criteria |
|---|---|
| **CANDIDATE** | Tested once, worked. Fragile. Expires 24h. |
| **PROVISIONAL** | Tested ≥3 times across ≥3 different substrates (machines, models, operators), no failures. Expires 7d. |
| **CANON** | Sealed in VAULT999 with F13 sovereign signature. Permanent. |

External AI self-verdict + your independent re-execution = 2 witnesses. **Third witness required for PROVISIONAL.** The third witness must be a different substrate — different machine, model, or operator.

## Anti-Patterns to Catch

| Pattern | Why it's wrong |
|---|---|
| **Trusting the witness claim** | "Witness: ChatGPT external instrument" doesn't mean the verdict is sealed. Witness means one independent substrate saw it. Canon requires sovereign. |
| **Re-running tests but accepting the example** | Example output is one case. Tests cover several. If example passes but tests fail, the artifact is broken at the margin, not in the happy path. |
| **Skipping the stdlib-purity audit** | External AI that delivers a kernel with `pip install requests` is creating a deployment surface you didn't ask for. |
| **Reading tests but not running them** | Tests can be wrong (asserting the wrong thing), skipped (`@skip`), or conditional. Run, don't read. |
| **Assuming "no repo mutated" without checking** | External AI may have a different definition of "the repo." `git status` is one line. Use it. |
| **Treating DRAFT_ONLY as final state** | DRAFT_ONLY is the verdict **for this delivery**. Promotion requires more witnesses. Don't close the loop early. |
| **Adopting without F13 review** | Even if everything passes, F13 ratification is sovereign-level. Don't auto-promote. |
| **Projected-template trap — PASS verdict from simulated (not executed) tests** | A subagent writes a script whose imports are **commented out** (`# from module import ...`), fills `results = {"precision": 0.94, "status": "PASS"}` inline, and the report reads as genuine. Detection: grep for the actual module being claimed — if the import is commented, the numbers are invented. Real test runners emit counts (`114 passed`), never hardcoded booleans. This was caught 2026-08-04 when a simulation subagent produced a "PASS" report from a script where every function returned a hand-filled dictionary; the re-executed version (with real module calls) returned NEEDS TUNING with 78% accuracy. |
| **NEEDS TUNING as genuine value — reject at your peril** | Inflating a partial pass to "PASS" to look good IS fabrication. An honest NEEDS TUNING with specific failure counts (e.g. REINFORCED 0/8 = 0% retention, Phase C ON_TOPIC 9/10 false alerts) drives real fixes; a fabricated PASS wastes the archive. The principle: real numbers preserve trust; nice-looking numbers destroy it. When you act on behalf of a sovereign, re-execute claims before reporting them — if you cannot re-execute, label the report INT not OBS. |
| **Invisible API rebuild between delegation cycles** | When multiple subagents run sequentially on the same codebase, a Phase-2 rewrite in one subagent can silently break the Phase-1 API surface before the next subagent arrives. Detection: compare expected vs actual class/function names before making patches. This was caught 2026-08-04 when `causal_tagger.py` was rebuilt from `tag_causal(text)` → `classify(sentence) CausalResult` between the build agent and the tuning agent — breaking all 15 causal tagger tests and the simulation harness. Fix: always run `python -c "from module import name"` before patching. |
| **Bundled `.pyc` files** | If `__pycache__/` ships with the zip, the bytecode may be stale. Always test against `.py`, never trust `.pyc`. |
| **Magic constants labelled as "calibrated"** | A coefficient of `2.20` for `(1-A)²` is calibrated if you ran sensitivity analysis. It's theatre if you tuned it to one example and shipped. |
| **Conceptual primitive smuggling** | A new conceptual primitive (QQQQ, FROST, EUREKA, whatever) must be marked HYPOTHESIS if not in canon. If the artifact treats it as established, downgrade confidence. |

## Pitfalls

- **Self-verdict accuracy ≠ artifact quality.** A self-verdict can be perfectly honest about a flawed artifact: "tests 6/6 PASS, no repo mutated, DRAFT_ONLY" — all true, but the artifact still has magic constants, untested edge cases, or undeclared deps. Don't confuse verdict hygiene with quality.
- **Theater of the example.** A worked example that lands exactly on a curated state (resources = 0.82, 0.70, 0.90, 0.65) is performance. Real verification requires variation, edge cases, adversarial inputs.
- **Witness stacking without substrate diversity.** Two ChatGPT sessions on the same machine with the same operator is one witness, not two. Substrate must differ.
- **Trusting `__pycache__`.** Python's bytecode cache can mask source changes. If the zip ships `.pyc` files, the visible code may not be what runs. Always `python -B` (no bytecode write) when verifying, or delete `__pycache__/` first.
- **Assuming "stdlib only" without auditing.** `from typing import ...` is stdlib. `from flask import ...` is not. `grep -rnE "from |import " --include="*.py"` and verify each top-level package against stdlib.

## Case Study: eureka_zen_kernel_v0.1 (2026-07-18)

**Drop:** `/root/.hermes/cache/documents/doc_8cb18ec19274_eureka_zen_kernel_v0.1.zip` (ChatGPT-delivered)

**Self-verdict claims:**
- DRAFT_ONLY ✅ verified
- 6/6 tests PASS ✅ independently reproduced (6/6 in 0.001s)
- Stdlib-only ✅ confirmed via import audit
- No repo mutation ✅ verified via git status
- No vault seal ✅ verified via seal_chain head
- Witness: ChatGPT external instrument ✅ confirmed
- Bundle example output matches re-execution: **all 15 digits identical**

**Where draft is right:**
- Identity normalization fix (`strip().casefold().split()`) is correct
- Routing ownership statement (arifOS owns contract, A-FORGE owns mutation, WELL signals only) matches constitutional doctrine
- QQQQ marked HYPOTHESIS, not canon
- "Thermodynamics" framed as analogy, not literal physical entropy

**Push back (yellow, all):**
- QQQQ weighting (0.30/0.25/0.25/0.20) asserted without derivation
- `(1-A)²` coefficient (2.20) calibrated to one example, no sensitivity analysis
- `MarginMetrics.deferred_zen_debt` uses `debt > 0.35` magic threshold, inconsistent with `debt_zen_threshold=0.45` in controller config
- Controller emits `Mode` but doesn't *act* — observation only, no A-FORGE lease-gate plumbing
- No F1-F13 floor identifier cross-reference in `KernelState`

**Verdict on the verdict:** Self-verdict is **accurate as written**. Confirmed by independent re-execution. Cannot promote past DRAFT_ONLY until: ≥2 more independent runs across different substrates, QQQQ derivation, debt threshold consistency, A-FORGE integration plumbing.

**Third-witness requirement:** Two more independent runs from different substrates needed for PROVISIONAL. Each must use different machine, model, or operator.

## Integration with Constitutional Floors

| Floor | How this skill protects it |
|---|---|
| F2 TRUTH | All claims tagged by evidence class (OBS/DER/INT/SPEC) before emission |
| F3 WITNESS | Explicit count of independent witnesses; substrate diversity requirement |
| F4 CLARITY | State machine table reduces entropy in the verdict |
| F7 HUMILITY | Magic numbers and uncalibrated coefficients flagged with severity |
| F9 ANTI-HANTU | Re-execution is the primary defense; bundled `.pyc` and unverified tests caught here |
| F11 AUDIT | Verdict block + receipt block leaves traceable evidence |

## Origin

Originated from the 2026-07-18 verification of `eureka_zen_kernel_v0.1.zip` — a ChatGPT-delivered metabolic controller for governed agents. The self-verdict block was honest and accurate, but the pattern of "external AI delivers code + self-verdict + witness claim" recurs enough to warrant a class-level skill. Specific kernels are facts; the verification protocol is a class.

The temptation to trust the self-verdict ("ChatGPT said 6/6 PASS, witness declared, verdict DRAFT_ONLY, that's enough") is the F9 failure mode this skill exists to prevent. Run it yourself. Always.

## Post-Verification Workflow (when sovereign says "fix it")

The verification protocol above produces an independent verdict. But when the sovereign says "fix all what needed to be fixed first" or "fix before publish," the job extends beyond verification into three phases:

### Phase 1: Fix Defects
Fix every yellow/red finding from the verdict. For each fix:
- Make the change in the isolated `/tmp/` copy, never the live repo
- Run the test suite after each fix — no batch-fixing without verification
- Document the fix rationale inline (why this threshold, why this weight)
- Mark all uncalibrated values as HYPOTHESIS with derivation explanation

### Phase 2: Sensitivity Analysis
For any magic number (coefficient, threshold, weight) flagged in the verdict:
- Write a script that varies the parameter across its plausible range
- Hold other inputs at the bundled example's values
- Map the decision boundary: what combinations of inputs produce each mode
- Document findings in a `SENSITIVITY_ANALYSIS.md` alongside the artifact
- **Key insight from eureka_zen_kernel:** The parameter you think is load-bearing often isn't. Run the analysis before claiming which coefficient matters.
- **Technique reference:** `references/sensitivity-analysis-technique.md` — full walkthrough with pitfalls.

### Phase 3: Integration Spec
If the artifact is intended for the live system, produce an `INTEGRATION_SPEC.md`:
- Which existing files to create/modify
- How to construct inputs from live system state (not hardcoded values)
- Pipeline position (where in the 000→999 cycle)
- Test strategy (unit + integration + conformance)
- Open questions for the sovereign
- Estimated effort

**Pitfall:** Don't merge Phases 1-3 with the initial verification. The verdict must be independent — fix it AFTER you've confirmed the self-verdict is accurate, not during. Mixing verification with improvement corrupts the independence of the verdict.

## See Also

- `claim-validation-protocol` — validates claims about the federation, not delivered code
- `evidence-before-elegance` — nine-gate framework for analytical essays and narrative outputs
- `forge-before-build` — whether to build a proposed improvement (different question)
- `governance-enforcement-audit` — audit whether a system's self-declared governance constraints are actually enforced