New here? Read START-HERE.md first (five minutes, no jargon). This page answers the questions people actually ask — including the skeptical ones, which are welcome.
Fair question, and the honest answer has two parts. The music mathematics is not numerology — it's ordinary mathematics, and a computer has checked the proofs the same way it would check any theorem (no human hand-waving, no "if you squint"). That part stands or falls as math.
The broader claim — that the same four-part pattern shows up in film, painting, physics — is not proven and is not presented as proven. It's an interpretive lens. The difference between this and numerology is that the lens is stated so it can be wrong: it makes specific claims you can push back on, and the project actively asks you to. Numerology protects itself from being tested. This tries to expose itself to it.
- Proven (machine-checked): the music results — why twelve notes, the unclosable gap (the "comma"), the special structural role of the tritone. See
validation/claims/why-twelve-tet.md. - A reading (not proven): that the four stances — work inside the gap, spread it, exploit it, refuse it — apply across other creative and scientific fields. Useful if it helps you see your field; not a settled fact.
If you keep those two boxes separate, you understand the project's honest state.
No. Most of the repo is written for specialists, but you can ignore all of it. If the idea made you think — especially if you know a field it touches — your reaction is useful as-is. Plain language is fine.
Not in the traditional sense, and it doesn't pretend to be. Validation happens in the open, here: claims are listed, experts are invited to confirm or correct them, and every outcome (including "an expert told me this was wrong") is recorded publicly. One paper is in the arXiv pipeline; the math results have been independently checked by specialists in correspondence. The project's whole premise is that the honest state of the work should be visible to anyone, not hidden inside a closed accept/reject process.
In this project's everyday sense:
- A kernel is the one basic move a field is built on — the perfect fifth in music, the cut in film, gravity in architecture.
- A comma is the small permanent gap that move creates and can't fix itself — like the way stacking perfect fifths never closes the circle.
(Both words also have unrelated technical meanings in mathematics; the project flags this so specialists aren't confused.)
Because it's the clearest and most testable case, and everyone has some intuition for it. The unclosable gap in tuning is real, ancient, and well-documented, and the mathematics around it is exact. Music is the place where the idea is on its firmest ground — so it's the right place to start and the right place to attack.
Honestly: that's the open question, and the part most likely to be partly wrong. The claim is that it applies; the evidence outside music is interpretive, not proven. If you work in one of these fields and think the lens distorts more than it reveals, that's exactly the feedback the project wants. Saying so is a contribution, not an intrusion.
You shouldn't trust it on those grounds — you should check it, which is why the proofs are machine-verifiable and the claims are laid out to be disputed. The AI involvement is disclosed in full, and one of the papers (Paper 2) is about exactly this problem: how knowledge made with AI assistance can carry errors, and what correction machinery catches them. The public claim list, the expert correspondence, and the commit history are that machinery. Trust the checking, not the author or the tools.
Several things, and naming them is the point:
- A field organized around a clear single "kernel" move where the four stances plainly don't describe how practitioners respond.
- The "refuse it" and "exploit it" stances turning out to be the same thing in practice (the project argues they're genuinely distinct).
- The music mathematics containing an error (a specialist finds the proof is wrong).
If you can produce any of these, you've done the project a service. That's how it's meant to work.
- Open a Discussion — plain questions and disagreement welcome, no formality. A good place to start: "Where does this lens fail in your field?".
- Or email
chris@falsework.dev. - Tell us where the lens rings true or false in whatever you know best. That's the most valuable thing a non-specialist can offer, and there isn't enough of it.