Mainscreen

Inspiration

LinchKey did not begin with a simple question.

It began with a mismatch.

I was repeatedly told that one rule, policy, or common professional understanding controlled a situation, while the governing law appeared to say something different. I have noticed those kinds of mismatches since I was young, but noticing them and explaining them are not the same thing.

Over months of research, I kept running into the same problem: people often relied on summaries, office practice, policy, or what they had been taught instead of returning to the controlling source itself.

One example became especially important to me. I was repeatedly told that the UCCJEA did not matter in removal, abuse, or neglect cases. I kept questioning that because the statute’s definitions appeared to include those proceedings. For a long time, the disagreement went nowhere. Eventually, someone finally asked where I was getting that interpretation.

The answer was the definitions section of the law.

That moment captured the problem LinchKey is designed to address. The issue was not hidden in an obscure footnote. It was in the governing text itself, but the analysis had started from a familiar professional assumption instead of from the source.

That kind of early shortcut can change everything that follows: which questions are asked, which parties are identified, which procedures are followed, what evidence is collected, whether notice and opportunity to be heard are evaluated, and whether due-process concerns are recognized.

I also needed a way to translate how my own brain works. I naturally notice mismatched names, missing steps, conflicting records, and details that do not fit the expected pattern. I often know that something is wrong before I can explain it in a clean, linear way.

Working with GPT-5.6 and Codex helped me turn that nonlinear pattern recognition into a visible reasoning structure that other people can inspect, verify, and understand without flattening the governing meaning.

LinchKey was built to make that process repeatable.

It begins with the controlling source, identifies the required elements, preserves uncertainty, separates independent pathways, and shows why a conclusion is supported, unsupported, or unresolved.

The current prototype uses interstate legal authority because it clearly demonstrates definitions, nested requirements, timing, procedural gates, independent duties, and downstream consequences. But the same architecture can support medicine, engineering, accounting, investigations, cybersecurity, regulatory compliance, research, contracts, and other fields where professional judgment should remain connected to what actually governs.

Find What Governs.

What it does

LinchKey is an explainable reasoning engine that identifies the governing pathway behind a conclusion instead of beginning with the most common answer.

It separates people, governing authorities, procedural requirements, evidence, dates, assumptions, and unresolved questions into independent reasoning paths before allowing a conclusion.

Rather than producing a single answer, LinchKey shows:

The governing source that controls the issue.
The required elements that must be established.
Which elements are verified, unresolved, or unsupported.
Why a conclusion is reached.
What would have to change before a different conclusion could be supported.

The current prototype demonstrates these concepts using interstate legal authority because it contains nested statutes, definitions, procedural requirements, jurisdictional rules, and independent duties that must all be evaluated separately.

LinchKey also supports continuous reanalysis. When new evidence is introduced or a governing authority changes, the system reevaluates every affected pathway instead of simply updating one answer while leaving downstream reasoning unchanged.

Although this prototype focuses on law, the reasoning architecture is designed to be domain-independent and applicable anywhere conclusions must remain connected to governing authority, verified evidence, and explainable reasoning—including medicine, engineering, cybersecurity, scientific research, accounting, regulatory compliance, investigations, and contracts.

How we built it

LinchKey was designed first as a reasoning architecture and then translated into an interactive prototype.

I designed the governing-pathway model, reasoning flow, source-first methodology, reanalysis process, and the separation of independent facts, authorities, procedural requirements, and downstream consequences.

Using GPT-5.6 and Codex, I translated that architecture into an interactive HTML application. Together we built the interface, refined the reasoning flow, debugged the GitHub Pages deployment, resolved service-worker caching issues, improved navigation, and revised the interface whenever generated output flattened required legal or logical distinctions.

The prototype is built with standard web technologies including HTML, CSS, and JavaScript, allowing it to run entirely in the browser without requiring a backend.

Throughout development, the focus was not simply generating code. The challenge was preserving the integrity of the reasoning architecture so that each governing pathway remained independent, explainable, and traceable back to its controlling source.

Challenges I ran into

The biggest challenge was not writing code—it was preserving the reasoning.

Traditional AI workflows naturally summarize, merge similar ideas, or simplify complex structures. For LinchKey, those behaviors often changed the governing meaning by combining independent pathways, removing required procedural steps, or treating assumptions as established facts.

Another challenge was translating a nonlinear reasoning process into a clear interface that other people could follow without losing the relationships between governing authority, evidence, dates, definitions, and downstream consequences.

On the technical side, I also encountered GitHub Pages deployment issues, service-worker caching problems, browser update delays, and repeated interface revisions as the prototype evolved.

Because LinchKey is designed around explainable reasoning rather than prediction, nearly every interface decision required balancing usability with transparency. The goal was to make the reasoning easier to understand without hiding the complexity that produces the conclusion.

Accomplishments that i'm proud of

In a short development period, LinchKey evolved from a reasoning framework into a working interactive prototype.

We demonstrated that complex, source-driven reasoning can remain transparent instead of becoming a black box. The prototype separates governing authorities, required elements, evidence, assumptions, procedural requirements, dates, dependencies, and unresolved issues into independent pathways while allowing users to inspect why a conclusion was reached.

I am especially proud that LinchKey helped translate the way I naturally process information into something other people can follow.

My reasoning often develops through multiple connected threads that may look scattered on the surface but follow the same underlying line. Before LinchKey, explaining those connections often meant sending long blocks of legal text, separate corrections, timelines, and pieces of analysis that caused readers to lose the thread or mentally check out before reaching the governing point.

LinchKey turns those pieces into a visible, more linear pathway without erasing the distinctions that made the issue matter in the first place.

That means I can now show:

where the reasoning begins;
how separate threads connect;
why a mismatch matters;
which authority controls each question;
what remains missing or unresolved;
and how an early assumption affects later conclusions.

I also built a browser-based prototype that runs without a backend, deployed it through GitHub Pages, and resolved significant deployment and service-worker caching problems along the way.

Perhaps the accomplishment i'm most proud of is preserving the integrity of the reasoning while making it easier for people to understand.

Rather than optimizing for the fastest answer, LinchKey is designed to optimize for reasoning that remains defensible, explainable, and connected to the governing source.

The current legal demonstration is only one implementation of a broader architecture that can expand into other domains where professional judgment, source control, and transparent reasoning matter.

What I learned

I did not build LinchKey because I learned assumptions matter. I already knew they did.

What I learned was that months of questioning, correcting, and refining reasoning with my own ChatGPT conversations were not wasted. Every time I pushed back against a flattened answer, restored a missing distinction, or asked "Where does the governing source actually say that?" I was gradually discovering the architecture that became LinchKey.

I also learned that reasoning can be translated.

My thoughts rarely arrive in a simple A → B → C sequence. They often look more like many connected threads that eventually converge. To me, the connections feel obvious. To someone else, they may seem unrelated until each intermediate step is shown.

Working with GPT-5.6 and Codex taught me that those nonlinear pathways can be translated into a structured process without losing what made them correct in the first place.

I also learned that what feels like an obvious step to me is often a missing step for someone else. Building LinchKey forced me to slow down, expose every connection, and explain why each step exists instead of assuming others would automatically see it.

That lesson changed more than the software.

It changed the way I communicate complex reasoning.

The result is a system that helps translate complex, source-driven reasoning into something people can inspect, verify, and follow—one governing step at a time.

Why LinchKey Is Different

Many reasoning systems begin by predicting the most likely answer.

LinchKey begins by identifying what governs.

Rather than hiding the reasoning process, it exposes every governing pathway, required element, verified fact, unresolved question, and dependency that contributes to the result.

Its objective is not simply to produce an answer.

Its objective is to produce reasoning that remains inspectable, challengeable, correctable, and connected to the governing source.

What's next for LinchKey

The current prototype demonstrates the reasoning architecture. The next stage is expanding that architecture into a broader, source-first reasoning platform.

Future development includes adding additional jurisdictions and eventually expanding beyond law into other source-governed fields such as medicine, engineering, accounting, cybersecurity, scientific research, regulatory compliance, investigations, contracts, and education.

I also want LinchKey to become increasingly interactive. Instead of simply returning answers, it should help users understand why a governing pathway succeeds, fails, or remains unresolved, while allowing them to explore alternative pathways, inspect supporting authority, and reanalyze conclusions as new information becomes available.

Long term, I hope LinchKey becomes a tool that helps professionals, students, researchers, and everyday users navigate complex source-driven questions without replacing their judgment.

The goal has never been to create a system that thinks for people.

The goal is to build one that helps people think more clearly, remain connected to what governs, and communicate complex reasoning in a way others can follow.

This prototype is only the beginning.