NASA patents its inventions
A patent is a legal right to an invention. NASA's public list names 1,393 patents and applications, from materials to sensors.
A knowledge graph, built on NASA patent data
When NASA licenses an invention to a company, someone must check five separate records first. GoNoGo runs those checks in under two seconds, then shows what it found and where each fact came from.
Start here
NASA invents things. Companies want to use them. A license is the permission, and granting one takes care.
A patent is a legal right to an invention. NASA's public list names 1,393 patents and applications, from materials to sensors.
A license lets a company use a patent for one purpose, in one place, for a set time. An exclusive license means no one else may.
The same invention cannot be promised exclusively to two companies for the same use, so the office checks five things first.
The error that costs most is approving a license that should have been blocked, because nothing flags it.
Orbital Lens Works, Inc. wants a non-exclusive license to NASA case LEW-17915-1 for optical communications in United States from January 1, 2027 to December 31, 2031.
The company is fictional. The case number is a real NASA invention. GoNoGo's answer is GO: the patent is in force, no grant overlaps, export is unrestricted, and the ownership record is complete with no co-owners.
Before anyone says yes, someone must confirm each of these:
Fees go unpaid and terms end. A snapshot can still say "in force" after the patent has lapsed.
Same use, same territory, overlapping dates. A broader grant covers a narrower request.
NASA must announce an exclusive license and wait for objections before it can sign.
Export control can forbid the technology from reaching the licensee's country.
When a university or company co-owns the patent, every co-owner must consent. A missing record is not a yes.
Why it is hard
Each check needs a different source, and each source writes things its own way. Two real notices name the same company as "GenH2" and "GenH2 Corporation". A field of use might be "optics" in one record and "lasers" in another, and the second is narrower than the first.
A system that trusted any single source would give wrong answers. So GoNoGo records where every fact came from, and when two sources disagree about a patent's status, the USPTO record wins.
The technology
A spreadsheet stores values. A knowledge graph stores facts and the relationships between them, along with a written definition of what each kind of thing means. That written definition is called an ontology.
"Grant 17 is about this patent." Each fact joins two things with a relationship. Join enough facts and you have a graph.
The ontology defines the kinds of things (patent, grant, licensee, field of use) and how they connect. GoNoGo's defines 48, so every source maps onto the same words.
Fields and territories form a family tree. A license for optics covers a request about lasers, and one for North America covers the United States. The graph states this once, and every rule uses it.
If nobody recorded the co-owners, they are unknown, not absent. The graph keeps "unknown" as its own state, so a missing fact can never turn into a yes.
When it was true in the world, when the system learned it, and where it came from. That lets GoNoGo rerun any past decision and get the same answer.
Models read messy sentences well and apply rules inconsistently (the benchmark below measures this). So in GoNoGo a model may read a question or propose a fact. Fixed rules decide, and a person approves any new fact.
New to ontologies? Read the guide that assumes no backgroundThe answer
Write the request as a sentence that names the licensee, patent, license type, use, place, and dates. GoNoGo runs the seven checks and gives one of five answers.
A missing fact is not a yes. If no ownership record exists, the answer is NO DATA, not GO.
How it works
The parser turns the words into a patent, a license type, a use, a place, and dates. It lists anything it cannot find as missing.
Each rule asks the knowledge graph a fixed question. The same request on the same records gives the same answer, every time.
Each fact records its source, who approved it, and when the system learned it. A past decision can be rerun exactly.
How it was built
Here is what each stage did, and what went wrong or surprised us along the way.
Five public sources were pulled and every raw response kept with its date. From them we chose 300 patents across three NASA centers (Langley, Glenn, and Kennedy) and every notice that names one.
What we found. The stale statuses and missing details described above. NASA does not publish agreements, ownership records, or export classifications, so a generator wrote 120 fictional agreements and 45 test cases. Each case has an answer written by hand, and every synthetic fact is labeled.
Before drawing a single class, we wrote 15 questions the system must be able to answer. Then came the ontology, the word lists for fields and territories, and shapes that check incoming data. A reasoner tests the whole model for contradictions.
What we learned. Two kinds of check catch different mistakes. A grant that named a country where a field of use belongs passed the shape check and was caught by the contradiction check, so every build runs both.
Seven rules, a combiner that turns their results into one verdict, a parser for the question, matching of company names, and a queue where a steward approves new facts. A public demo ran the whole loop in a browser.
What we learned. A wrong approval is acted on exactly like a right one. In the demo, approving a record that left out a co-owner changed the verdict from COUNSEL to GO. Nothing in the engine could catch that, which led to the two-person rule.
Policies decide who may do what, and an approval that conflicts with the record or would raise a verdict waits for counsel. Tests tried to leak confidential royalty terms and to plant instructions inside agreements. The system then ran on AWS with real sign-in, passed 11 live checks, and was torn down.
What we learned. No model obeyed a planted instruction in 36 tries. That is a small sample, and the write-up says what it does and does not prove.
200 questions went to four ways of answering. A second database, built for graphs of a different kind, ran the same overlap rule in its own language. A workflow now reads an agreement PDF, extracts a grant, and waits for a steward.
What we learned. A model that was given the right facts still got the answer wrong 27.5% of the time. And when the second database was loaded with a wrong identifier, it returned nothing and only logged a warning, where the first database's checks would have stopped the load.
Why it was built this way
Because a model of the world should answer real questions. A class that no question needs gets cut.
Because otherwise a patent nobody checked would be approved. The answer for a missing fact is NO DATA.
Because the benchmark showed that models misapply a rule even when they hold the right facts. The same rules give the same answer every time.
Because a decision must be explainable and repeatable months later, and an auditor must be able to rerun it.
Because the first demo showed that one wrong approval could change a verdict. People are fallible, so the system asks for a second.
Because royalty terms must never leak. Only one role may read them, and every export and demo leaves them out.
The proof
Two hundred clearance questions went to four ways of answering, scored against verdicts fixed by hand when each case was planted. All four had the same facts.
The agent cited the deciding agreement 91% of the time and still misapplied the rule. The model reads. The rules decide.
The questions are synthetic and few: 45 planted cases, each asked four ways, plus 20 that cannot be answered as asked. They test every rule and its hard edges, but they were written by the same project that wrote the rules. One model (Claude Haiku 4.5) was used throughout. Read the method, the failures, and the limits.
Built for the people who sign off
A model may propose a fact. Only people approve it, and the system requires a second approver when one is not enough.



Textract reads it, fixed patterns extract the grant, SHACL checks it, and a workflow waits for a steward. A planted instruction inside an agreement changed no verdict.
Cedar policies decide which role may read which graph. Royalty terms never leave their own graph and are excluded from every export and demo.
Every decision stores its cutoff, release, facts, and a signature, with a locked copy. An auditor reruns it and gets the identical answer.
For the practitioner
The classes and properties are defined in the ontology file, and sixteen written modeling decisions explain the choices behind them. Fifteen competency questions, written before the model, check that it can answer what the rules ask.
Architecture
Seven views, drawn with the AWS icon set. The graph sits in a VPC with no route to the internet, and only two functions may write to it. Click a diagram to enlarge it.
Numbers follow one clearance question from the browser to a stored, signed decision.
Fifteen steps from sign-in to a stored decision. The role comes from the token, never from the request.
A Step Functions state machine waits for a steward with a task token before anything reaches the graph.
No NAT, no internet gateway, no interface endpoints. Eleven checks ran against the live stack and all passed.
Which role may query which graph, read from the Cedar policies when the diagram is built.
The same questions and the same facts go to every answerer. Only the method differs.
Deployed for a session, checked, and torn down by one script. Only the graph database bills while idle.
Watch
The ontology, the trail behind a fact, the path to a verdict, the AWS design, and the benchmark. Captions included.
Beyond patents
A studio clearing a film for streaming asks a question of the same shape: who holds which rights, where, and when, and does a new request collide with an existing grant?
Explore