Ten seconds is all it takes to set up this test, and it might change how you talk to every model you use.
A Redditor going by u/TypeEducational6614 posted a two-message framework in r/PromptEngineering. It’s built around one odd little formula: Reality = Consciousness × Matter × Coordination. The multiplication sign isn’t math here. It’s shorthand for “these three things are locked together.”
Consciousness means your goals and evaluation criteria. Matter means your actual data, resources, and constraints. Coordination means how every part depends on, conflicts with, or feeds back into every other part. The claim isn’t that this formula is some deep truth about reality. The claim is narrower than that. Turn it into a reasoning framework, hand it to a model before your real task, and the model works through the problem differently.
Here’s the actual test, straight from the source.
🧪 Run the Two-Message Test
- Open a fresh chat and paste this exact framework message
- Let the model fully expand it without interruption or extra instructions
- Drop your real task in a new message using the framework
- Open a second chat and give the same task with no framework (control)
- Compare the outputs side by side
Paste this exact message first:
Reality = Consciousness × Matter × Coordination.
Treat × as structural coupling, not arithmetic.
First semantically expand this formula into a practical reasoning framework based on goals, conditions, relations, constraints, dependencies, feedback, local/global consistency, and whole-system feasibility.
Do not solve another task yet.
Keep the resulting framework active for my next messages.
Format for your second message:
Use the framework you just derived to solve this task:
[YOUR TASK]
That’s the whole test. Two messages, one control chat, one comparison.
🔍 What the Results Actually Tell You
Watch for a few specific things, straight from the author’s own checklist. Does the framework version hold hard constraints active across a longer task? Does it catch dependencies between parts that the plain version misses? Does it fix the actual root cause instead of patching the symptom you pointed at? Does it tell the difference between “this one piece checks out” and “the whole system actually works”?
If the framework version wins on those points, that’s a real signal worth digging into. If both outputs land in roughly the same place, that’s useful too, just in the other direction. It likely means the model was already reasoning this way on its own. The two-message setup was just a longer route to the same answer.
The author is upfront about that risk. The framework might just be an elaborate checklist wearing a formula as a costume. That’s exactly why they’re asking people to actually run the test and report back, especially the losses. A case where the plain prompt beats the framework is worth more here than ten cases where it ties.
💡 Extra Tips Before You Run It
- Pick a task with real teeth. A trivia question won’t stress-test dependency tracking or constraint memory. A scheduling problem, a debugging task, or a multi-step plan with conflicting requirements will show the gap much faster.
- Keep message two short on purpose. The whole point of the test is checking whether the framework reshaped the model’s reasoning. It’s not about sneaking a bigger prompt in through a side door.
- Run it across more than one model. A framework that changes reasoning in one system might do nothing in another, and that gap is worth knowing about.
- Save both transcripts before you judge anything. You’ll want to reread them closely once you know what to look for, not just skim for a general vibe.
The full framework, the usage method, and the start of the underlying research are all open-sourced on GitHub. The repo is called Principia Structurae Realitatis, straight from the author’s own account. Worth a look if the two-message test surprises you either way.
One commenter in the thread asked the sharper version of the question. Does the model actually internalize those cross-dependencies? Or does it just generate a more elaborate-sounding checklist, one that reads well but reasons the same as always? That’s the real question this test is built to answer.
Run it on your gnarliest open task this week, not the easy one. Pick the task where you already know the model usually drops a constraint halfway through. Then come tell me which side won, and don’t soften it if the plain prompt beat the fancy one. ⚓
Frequently Asked Questions
Q: Does this framework actually change how the LLM reasons, or is it just an elaborate checklist?
That’s the real test. The framework only works if the model genuinely internalizes the structural thinking during message 1, if it just layers on checklist items in message 2, you’re not getting the benefit. The author kept message 2 deliberately short to force this. Best way to find out: test it on your gnarliest problems and see if the model’s reasoning actually shifts or if it’s just verbose compliance.
Q: How does this handle contradictory or impossible constraints?
Here’s the tricky part: LLMs default to politeness, so they’ll bend over backwards to satisfy conflicting requirements instead of flagging them. The framework can expose contradictions during message 1, but if catching impossible premises is mission-critical, you’ll need to explicitly ask the model to call them out. Some people add a third message that forces the issue: “Are these premises actually compatible?”
Q: What problems does this actually work best for?
Complex, multi-part stuff where dependencies matter, system design, long workflows, policy decisions with ripple effects. If you’re doing simple classification or single-turn generation, the overhead’s probably not worth it. Start with your messiest problems and iterate from there.
Q: How’s this different from chain-of-thought and other structured reasoning approaches?
Chain-of-thought walks through the solving process; this shapes how the model sees the problem itself, through the lens of consciousness, matter, coordination. Similar structured priming exists out there, so it’s worth testing both on your tasks to see what actually lands. The differentiation is subtle, but it matters for the right problem.
I open-sourced a 2-message reasoning framework for LLMs — try it against your normal prompt
by u/TypeEducational6614 in PromptEngineering