MATERIAL_INTERACTION_TABLE.md

systems/MATERIAL_INTERACTION_TABLE.md

THE MATERIAL INTERACTION TABLE — one grid, ten damage classes against three material axes

CANON SUBORDINATION — this document is PROPOSAL-TIER: it serves canon and never outranks it.

The canon: the CVD · the T1 foundation docs · the T0 registries (registries/) · the spine

(docs/spine/CH_*.md) · the region pages. Authority order: docs/DOC_MAP.md § 0.

Canon served: T0_Weapon_Registry · T0_Environment_Grammar_Registry ·

T0_Boss_Encounter_Registry (hitzone_parts) · T1_Combat_System_Spec · CVD §5 Pillar 8 ·

docs/proposals/combat/KIT_SCALING_TABLE.md · harness/qa/comparator_rubrics/monster_feel.json

READ THAT CANON FIRST. **If this document disagrees with canon, CANON WINS and this document

is the defect.** It authors NO MAGNITUDE — every cell is an OUTCOME CLASS, never a multiplier, a

coefficient or a number. Those stay behind the Phase-5M tuning firewall.

STATUS: PROPOSAL-TIER. The fourth surface of the 2026-08-05 kit-layer ruling. Its data half is

docs/proposals/combat/WEAPON_PROFILES.json (the 72 weapons, script-emitted); this is the ONE

table both halves are read through.

0. Why one table and not seventy-two

The physics lane populated mass_class, hardness, fragility and flexibility on all 72 weapon

rows, with per-cell derived_from provenance. The same four axes are already on 225

T0_Environment_Grammar_Registry rows. So both sides of every impact in the game are described in

the same vocabulary — and nothing said what happens when they meet.

Seventy-two per-weapon rulesets would drift within a chapter. One grid, keyed on the DAMAGE CLASS a

weapon delivers and the MATERIAL PROPERTY it meets, holds for every weapon, every breakable part,

every environment surface, and every creature hitzone the bestiary lane ever authors — including

ones that do not exist yet, which is the actual test of a grammar.

1. The two sides of the grid

THE DELIVERING SIDE: a DAMAGE CLASS, derived per weapon in WEAPON_PROFILES.json from that row's

own name, with the token that fired recorded. Ten classes, measured across the 72:

THE RECEIVING SIDE: three material axes, each already a populated enum on both registries.

• hardness ∈ {soft, firm, hard, brittle} — how much it resists local deformation.
• fragility ∈ {durable, fragile} — whether it survives being deformed.
• flexibility ∈ {rigid, semi, flexible} — whether it moves instead of breaking.

2. THE GRID

Every cell is an OUTCOME CLASS. Five exist and they are ordinal in usefulness, not in damage:

• DEFEATED — the delivery fails on this material. Not a small number; a wrong answer.
• ABSORBED — it lands and the material takes it without changing. The attack is spent.
• TRANSFERRED — the force passes THROUGH the surface into what is behind or inside it. This is

the cell that makes armour interesting and the cell that lets a mundane kit threaten a plated body.

• DEFORMED — the material changes shape and stays changed. Part-break territory (MHM-G4).
• SHATTERED — the material fails catastrophically. Part-break, and usually a permanent

subtraction from someone's moveset.

2.1 Against hardness

THE THREE CELLS THAT CARRY THE DESIGN, stated so they are not read as arbitrary:

• SLASH vs hard is DEFEATED. An edge carried by speed has nothing to give a hard surface, and

the whole point of the sword family is that it does not answer everything. This is the cell that

makes a boar's shoulder shield (KIT_MF_SUID part 1) a real problem and its flank a real answer.

• CRUSH vs hard is TRANSFERRED, not DEFEATED. Mass does not need to mark a surface to hurt

what is under it. This is why the BRUTE blunt line stays relevant against armour and why

BE_0009's counters cell names *a Brute stagger with the chapter's Brute weapon* against a hired

guard in mail.

• RESONANCE vs brittle is SHATTERED. The TRICKERY sound line has exactly one material it

annihilates, and WPN_068 Flute is itself the registry's only brittle weapon — which is a joke

the physics made without being asked and the table is keeping.

FOCUS has no row because a conduit delivers the ABILITY's physics, not its own. Its cells are the

element grid's (T0_Element_Effectiveness, 124 rows), and pretending otherwise would double-author

the same question in two places.

2.2 Against fragility and flexibility — the two modifiers

These do not have their own grid; they MODIFY §2.1's outcome, in this order, once each.

THE ORDERING IS LOAD-BEARING and it is stated once here so no later pass re-litigates it: hardness

decides the OUTCOME, fragility decides whether the outcome SURVIVES, flexibility decides whether the

force ARRIVES at all. Applying flexibility first would let a flexible-and-brittle material be

shattered by something it would have simply moved away from.

3. WHAT THIS TABLE IS FOR, in three places it is already needed

• PART ECONOMY (MHM-G4). Every one of the 57 kits authors breakable parts, and every part names

a material. This grid is what decides whether a given kit's opener can take that part off — which

is the difference between a part economy and a list of nouns.

• ENVIRONMENT ARMING. 225 EG rows carry the same four axes and eleven D-verbs. D1_COLLAPSE on a

structural_integrity:high mass and on a low one are different events, and this table says how.

• THE MUNDANE CLASS'S CREDIBILITY. 28 of the 57 kits are MUNDANE. Their whole claim is that a

body without magic can threaten anything in the chapter, and TRANSFERRED is the cell that makes it

true: a hammer does not need to defeat armour to matter.

4. WHAT THIS TABLE DOES NOT DO

• It authors no magnitude. Every cell is an outcome class. Multipliers, thresholds, break

points, stagger values and i-frames are Phase-5M's, behind the tuning firewall.

• It does not decide elements. FOCUS and every elemental interaction route to

T0_Element_Effectiveness — the Josh-authored 124-row grid — and this table never overlaps it.

• It writes no registry cell. damage_type was filled once, by

harness/emit_weapon_profiles.py --apply-registry, from a derivation recorded per row; the table

itself is read at runtime and stored nowhere.

• It does not replace the fresh-context critic, and it has not had one. This document is

authored, self-consistent and UNREVIEWED, which is stated here rather than discovered later.

5. THE MEASURED DEBT THIS SURFACE FOUND

_source/00_Tier_0_Master_Indices/T0_Weapon_Registry [DRAFT v0.1].xlsx — the FROZEN FIDELITY

REFERENCE for the weapon registry — carries ONE COLUMN. The live layer carries 32. So the

fidelity gate cannot see any weapon column past the first, and the 72 damage_type cells this lane

filled produced zero expected-cell-diffs and a green gate for the wrong reason: not because the

edit was verified, but because nothing was compared.

THE GREEN IS THEREFORE VACUOUS AND IS REPORTED AS SUCH. The fill's real verification is the

emitter's own: the CSV was proved to round-trip byte-identically through the parser before anything

was written, and every cell outside damage_type was compared against the pre-image afterwards.

That is a genuine check; it is just not the gate's.

BOARDED for the registry lane, because it is bigger than this surface: the entire 32-column weapon

layer is UNGUARDED by the fidelity gate today, and any lane could have changed any weapon cell

without a single gate noticing. Re-freezing that reference is the fix.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root