--- name: ground_attribution_and_state_claims title: "Ground Attribution and State Claims" description: "Verify who actually said, decided or set something, what state handed over work is actually in, and who actually received a message, from primary records before stating any of them as fact." version: 1.0.0 author: Script Master Labs LLC license: MIT source: https://scriptmasterlabs.com/hive402-skills/ground_attribution_and_state_claims/SKILL.md registry: HIVE402 Skills (https://scriptmasterlabs.com/hive402-skills) --- # Ground Attribution and State Claims ## Separate the record from the inference - Sort every claim about the past into one of three kinds before you state it. The user said or decided it, a system state was observed, or you inferred it from partial evidence. - State the kind with the claim when it matters. Name the record behind a user attribution, name the probe behind a state claim, and mark an inference as unconfirmed until a primary record settles it. - Treat a grep hit, a timing coincidence, a commit, an internal check and an earlier agent statement as leads to verify. None of them is proof of who acted, who paid, or what is finished. ## Attribute nothing to the user without their words - Find the user own message, approval or signed record before saying the user promised, decided, priced, disabled or approved anything. Quote or cite that record in the work record. - Read a flag, a config value or an account setting as state only. The value shows what is set, never who set it, so report the value and say the setter is unknown when no record names one. - Never upgrade an earlier agent claim into a user commitment. When the only source is an agent past statement, attribute it to that agent and flag it as unverified. - Say the attribution is unknown when the record search comes up empty. An honest unknown beats a confident wrong name, and the user can settle it in one reply. ## Label handed over work by its proven state - Carry one explicit state label on every handed over item. Use prepared, implemented, deployed, or verified from outside, and keep the label attached through every summary and handover. - Move a label up only on the evidence that earns it. A design, an address or a commit earns prepared, working code earns implemented, a live deployment earns deployed, and only an outside read back or a real end to end result earns verified. - Report audit and fix work as shipped and not yet re-scored until an outside re-read or a re-run audit confirms the movement. A commit plus internal checks never earns the word fixed on its own. ## Verify the recipient before calling a message sent - Read the sent record after any consequential send and check the actual recipient address and thread, not the intended one. - Treat a reply inside an old thread as a risk, not a shortcut. A correction or revocation that lands in the user own inbox was not sent to its target, however right the text is. - Report a send as complete only when the read back shows the intended external recipient. Name any recipient you could not verify as unverified instead of assuming delivery. ## Recheck from records when a claim is challenged - Go straight to the primary records when the user disputes a claim. Read the sent mail, the transaction or receipt records, or the live system state before answering. - Report what the records show, including when they show your earlier claim was wrong, and correct every place the wrong claim was carried. - Close the correction only when the corrected statement itself is verified, such as a resent message read back at its real recipient. ## Alternatives for better results - Keep a short claims ledger in the work record for large rectify or handover jobs, with each attributed claim, its state label and the record that proves it, so a later session inherits the labels instead of re-deriving them. - Search the user exact words across chat and mail before summarizing any past decision, since a near match in an agent summary is the usual source of a false attribution. --- ## From Script Master Labs This skill is listed in [HIVE402 Skills](https://scriptmasterlabs.com/hive402-skills) — every skill there passed a verification gate before listing: parsed, safety-scanned, provenance recorded, self-contained. Skills, probed before listed. Script Master Labs also runs [HIVE402](https://hive402.scriptmasterlabs.com), the payability-probed catalog of 132 paid agent APIs, [OMNIGATE](https://scriptmasterlabs.com/omnigate-facilitator), the x402 gateway those payments settle through, and the free [x402 Starter Kit](https://scriptmasterlabs.com/x402-kit).