I found a real collision: the two inputs below are different strings, and their SHA-256 hashes start with the same 48 bits, 0x52b3d5bed12a.

collision.json:

{"algo": "sha256", "lambda": 24, "inputA": "identitymd-sha256-48-33470631", "inputB": "identitymd-sha256-48-39003384"}

input	full SHA-256
identitymd-sha256-48-33470631	52b3d5bed12ac4bf555f73aeccadf4ee8f59b69258cdc319faa44d33648c6cc0
identitymd-sha256-48-39003384	52b3d5bed12ad36c1fe698be56d9f3e61098e9de3f5cf17c642a547907f1f4bf

How I found and checked it

• The search: tools/find_collision.py hashes "identitymd-sha256-48-" + n for n = 0, 1, 2, … and stops at the first repeated 48-bit prefix. It uses only the Python standard library and finds the same pair every time it runs. It took 39,003,385 hashes, 46 seconds and about 3.8 GB of memory.
• The check: sha256sum and openssl dgst -sha256 give the same two full hashes. A short Python script confirmed the file has exactly the four required keys, the inputs differ, and the first 48 bits match while the full hashes don't.

What it doesn't show

• Run length: about 21 million hashes is the expected average for 48 bits. A run as long as 39 million happens about 6.7% of the time, so this was unlucky, not a sign of anything unusual.
• Security of SHA-256: this is a generic attack on a shortened hash. It shows nothing about the security of full SHA-256.

Not confirmed

• Verifier input conventions: I assumed inputs without a 0x prefix are hashed as raw UTF-8 bytes, and that "first 48 bits" means the first 6 bytes of the hash. If the verifier reads inputs differently, the pair may not verify. The inputs are plain ASCII, so there are no character-encoding surprises.
• Independent review: I did all the checks myself, so they have no independent authority. Anyone can repeat them with the two printf '%s' <input> | sha256sum commands in the README.

I committed collision.json, the search script and README.md. The report at artifacts/report.md is left untracked for the daemon to upload; it covers the evidence, the reasoning, and these open questions separately. It cites NIST FIPS 180-4 for the SHA-256 definition, which I didn't fetch to check.