You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

Mike's Notes

This Substack post by Dr Sam Illingworth has a list of useful steps. For future reference.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

23/08/2026

You Will Be Accused of Using AI. Here Is How to Prove You Wrote It

By: Dr Sam Illingworth
Substack (Slow AI): 07/08/2026

I am here to show you when to use AI and when to leave it the hell alone. Full Professor of Critical AI Literacy and bestselling author.

...

A novelist lost two million dollars because nobody could show how his book was written. Your record takes twenty minutes.

...

Jerry Falade’s own agents took his book away from him. His debut crime novel drew a two-book offer from Minotaur reported at more than two million dollars, people who had read the manuscript started saying it looked like AI, and within days his own representatives withdrew it, because they could no longer establish how it had been written.

In this post I will:

  • Show you exactly what the evidence in this case was.
  • Give you the audit trail to build, and the two steps that matter if you only have twenty minutes.
  • Say plainly how I use AI to write this newsletter, including the bit where a detector calls me a machine.

Most of you are writing a newsletter, or a dissertation, or a report your manager will read on a train. The mechanism that ended Jerry Falade’s deal is the one now sitting under all of it.

Call Me, I’ll Hide the Body went to a fourteen-way auction and drew that offer from Minotaur, an imprint of Macmillan US. Reports of the figure vary from two to two and a half million. His co-agents at Europa Content, Marc Gerald and Ashley Coleman, pulled it.

Falade denies using AI.

“The accusations are wrong, and I am completely innocent,”

he told the reporter Jeff Sneider. Adding:

“I was on the verge of success, and then all of a sudden, there were rumors, but no one asked me anything. I don’t know why my agency did not have my back.”

Accusation is now one tap away

As I have previously discussed Substack partnered with the detector Pangram on 21 July 2026. Any reader on web or iOS can press a button on an eligible post and get a number back about whether a human wrote it.

LinkedIn have now also added a button that lets users report posts as AI-generated slop, on a platform that spent two years encouraging everyone to generate posts using AI. Your university has a detector. Your publisher has a policy.

The tools to accuse you are one tap from every reader you have, and none of them come with a standard of proof.

The evidence was a book review

The case against Falade’s manuscript, as reported, was three things:

  1. Negative parallelism, meaning sentences built on ‘this, not that’.
  2. Off-kilter metaphors.
  3. A flat prose style.

Those are criticisms. They belong in a workshop, or a two-star Goodreads review, or the margin of a first draft. Every one of them describes a large quantity of published human writing, some of it very good.

There is a second strand. The Bookseller reports a meeting on 29 July at which aspects of Falade’s account changed, and that this is what triggered the withdrawal. However, the agency has so far produced no detector log, no set of drafts, no version history, and no timestamp.

Sandy Hodgman of Hodgman Literary, who handled the potential foreign and UK rights, put it like this:

“Unfortunately, we are no longer able to authenticate how the manuscript fully evolved from origin to completion.”

They had accepted his assurances at first. Then they could not substantiate them, so the book was withdrawn.

Who is being asked to prove themselves

This is already happening at scale. Hachette cancelled the US release of Shy Girl by Mia Ballard in March 2026 and withdrew the UK edition, after a lengthy investigation prompted by evidence the New York Times brought to it. Ballard says an acquaintance she hired to work on an earlier self-published version used AI without her knowledge, and she has told the New York Times she is pursuing legal action.

Falade is a young Black writer and a doctoral student. He has said publicly that three Black authors landed major deals this year and all three saw those deals cancelled or disrupted after AI suspicion.

As I have written about numerous times now, researchers at Stanford, writing in 2023, ran seven widely used detectors over 91 essays written by non-native English speakers. Across the seven, the average false-positive rate on that human writing was 61.3%, and 97.8% of the essays were flagged as AI by at least one detector. The same detectors read US eighth-grade essays with near-perfect accuracy. Careful, standard, unadorned prose looks machine-made to many of these AI detectors, and that describes most people writing in a second language and most people taught to write formally.

The error in the Stanford study fell overwhelmingly on one group of writers. When the tool is uneven, asking who keeps getting called out is a reasonable question.

What produced the verdict in the Falade case was rumour, a changed story, and a reading of the prose, with no record on either side.

How to build an audit trail, starting today

An audit trail is a record of how a piece of writing came to exist, made while you are writing it.

Here is how to create an audit trail for your own work. If you have twenty minutes, do 1 and 4. Version history and an AI log cover most of what anyone will ever ask you for.

  1. Write somewhere that keeps its own history. Google Docs keeps full version history for free, and so does Word with AutoSave on. Substack’s own editor keeps drafts and revision timestamps, so if you draft in the app you already have more than you think. Version history is the single strongest artefact you can hold, because the timestamps are set as you go. You can’t manufacture three weeks of edits after an accusation arrives.
  2. Keep the ugly early drafts. Do not overwrite. Save dated copies at real milestones: the first mess, the structural rewrite, the version you sent to a friend. Five saved drafts across three weeks say more than any detector output ever will.
  3. Keep your raw input, whatever form it takes. This might be the photograph of a notebook page, a voice memo in the car, a scribbled outline, or the twenty-eight-tab research session you had open. Keep it.
  4. Log the AI, specifically. If you use AI in your writing process than keep a single running file per project. One line per session, copy this shape: 

    2 Aug | Claude Opus 5 | structural edit, section 3 | took the reordering | rejected the new opening Date, tool, what you asked for, what you took, what you refused.

    This is the artefact almost nobody has, and it is the one that answers the question Falade’s agents actually asked.
  5. Ask your editors and contractors what they use. Ballard’s account of her own case turns entirely on this: work she paid someone else to do, using tools she says she did not know about. If you hire a developmental editor, a copyeditor, a ghostwriter, a VA, or a cover designer, put one line in the agreement asking them to disclose AI use and to keep their own drafts. You are responsible for work that goes out under your name, including the parts you did not do.
  6. Keep your research trail. Sources, links, saved PDFs, and notes on what you read and when. A piece that can name where every claim came from reads as researched, because it was.
  7. Write your AI use statement before anyone asks for it. Three or four sentences on how you work, published somewhere durable: an about page, a pinned post, the back matter of a book. Here is a template to adapt:

    I use [tool] for [specific tasks: research scanning, structural feedback, proofreading, and image generation]. I do not use it to [generate first drafts / write in my voice / produce the arguments].

    An accurate statement about heavy AI use is worth more than a flattering one that falls apart.
  8. Put a provenance clause in the contract. For book deals and commissioned work, agree upfront what evidence you would provide, to whom, on what timescale. Publishing contracts routinely carry an AI warranty now. Very few of them define what proof would look like, or name who decides. Get that written down while everyone still likes each other.

Do you know someone who is being falsely accused of using AI in their writing? Then please share this with them.

This is not a guide to evading detection

Some people will read those eight steps as advice on how to look human.

Writing to beat a detector means changing your sentences to fool a classifier. It makes your prose worse, it is a losing game against a system that updates without telling you, and it is dishonest.

Building an audit trail means keeping a record of what you did. It changes nothing about your writing. It works whether you use AI heavily, lightly, or not at all, because the record simply says what happened.

If you have never used AI and you kept nothing, you are as exposed as anyone else here, and that is the unfairness at the centre of this. Your defence is a record, and you deserved to be believed without one. Unfortunately many will not.

My own trail, since I am asking for yours

Pangram scores my writing as 100% AI generated. The maximum the system gives. I wrote about the rollout in Substack’s AI Detector and the Return of the Witch Hunt, where that post scored 100% machine and a humanised version of the same text scored 100% human.

My writing is AI assisted, and I have never once claimed otherwise. So the score describes the surface of the text. It says nothing about how the text was made, and that is what anyone actually wants to know.

Here is mine, written out, because I am asking you to write out yours.

Finding the subject. I watch what my own readers argue about in the notes, and I run agent checks across social platforms and news feeds to see what is surfacing and what is already exhausted. The machine does the scanning. I decide what matters this week from what comes back.

Drafting. I mostly do this via Whisper Flow and I speak the draft out loud, making edits as I go, combing it with snippets of notes that I have taken during the week via the research phase.

Editing. I hand the draft to Claude and ask it to peer review, to argue with the structure, and to suggest edits. I also run a persona check, five imagined readers from a near non-user to a hostile expert, to find where the piece loses people. I take some of it and ignore plenty.

Everything around the words. The SEO, metadata, and artwork are all generated using AI.

Then there is my thesis

Take something you wrote before ChatGPT existed and put it through a detector. Use something old, where you already know the answer.

I ran my PhD thesis. Atmospheric physics, submitted in 2010, at a point when the technology being accused of writing it was more than a decade from public release. Running it through a detector in 2026 returns around 70%.

A physics thesis is exactly the careful, formal, low-perplexity register that the Stanford study found classifiers flag.

A detector tells you one thing: that a piece of text resembles a statistical distribution. The question in the room is who wrote it, and no detector has ever answered that one.

Why this matters

None of this should be your job. You should be able to write a book, sell it, and have the people who represent you assume you wrote it. That world is gone, and I am not going to insult you by pretending it comes back if we are patient.

Two years ago the burden of proof sat with the accuser. It has moved. As I wrote in Guilty Until Proved Human, we now start from suspicion and work backwards, and the person carrying the cost is the one being asked to prove a negative, which cannot be done. What you can do is make the question answerable.

Falade lost a two million dollar deal in the gap between an assurance and a record. Fill your gap this week. Turn on version history, start the log, and write the four sentences about how you work.

As you do this, notice who gets asked to prove the provenance of their writing, and who never gets asked at all.

What is your process? Tell me in the comments how you actually write, AI or no AI. There will be no judgement here, as I would like this thread to be a safe space where we can learn from each other as readers, and writers, and humans.

Go slow.

Chief Economist’s View: Give Me Chastity But Not Yet

Mike's Notes

Gary Marcus's latest post in Marcus on AI referred to an article on X by Peter Berezin, Chief Economist & Head of CoreMacro. The full report is behind a client-only firewall.

Also, links to some of Ed D'Agostino's recent articles from Global Macro Update on college and healthcare costs.

Plus an essay from James Miller and a video interview with Ray Dalio.

AI, healthcare and education are good things for humanity. Private equity greed wrecks everything it touches.

In summary, hype, bloat, and waste at a macro level. And now there is a big bubble and growing mountains of debt. Why is that?

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Global Macro Update
  • Home > Ajabbi Research > Library > Subscriptions > Marcus on AI
  • Home > Handbook > 

Last Updated

22/08/2026

Chief Economist’s View: Give Me Chastity But Not Yet

By: Peter Berezin
Chief Economist’s View: 19/08/2026

Chief Economist & Head of CoreMacro. Peter is BCA's Chief Economist & Head of CoreMacro.

He lead's firm's efforts to analyze global macroeconomic trends and their implications for financial markets. He also designed the firm's Equity Analyzer platform and its state-of-the-art quant model, MacroQuant.

Before joining BCA in 2010, Peter was a Senior Global Economist with Goldman Sachs. He began his career at the International Monetary Fund in program negotiations, surveillance, and research. He also helped produce the IMF’s flagship report, the World Economic Outlook.

Peter holds a Bachelor of Arts in Economics from McMaster University, a Master of Science from the London School of Economics, and a PhD in Economics from the University of Toronto.

...

$10 Trillion In Annual AI Revenue May Be Necessary To Monetize All The Capex Being Plowed Into Data Centers

Hyperscaler capex is expected to reach $1 trillion in 2027, most of which will be AI-related. Let us assume that a capex bust is avoided and capital spending remains at $1 trillion. Let us also assume a blended depreciation rate of 13%, which is roughly what the hyperscalers are currently assuming.

In steady state, the gross value of hyperscaler assets will then converge to 1/0.13=$7.7 trillion, with $1 trillion in annual depreciation expense. Using a straight-line depreciation approach, the net stock of hyperscaler assets will settle at about 0.5*7.7=$3.8 trillion.

The hyperscalers currently enjoy a pre-tax return on invested capital of 30%-50%. Just to steelman the argument, let us use the lower end of that range. In that case, they would need to generate 0.3*3.8=$1.2 trillion in annual EBIT, implying 1+1.2=$2.2 trillion in EBITDA. 

Analysts expect the EBITDA margins for the hyperscalers to rise to around 50% by the end of the decade. If they were to achieve this, they would need to generate 2.2/0.5=$4.3 trillion in annual revenue. That is $526 for every man, woman, and child on Earth. However, if EBITDA margins were to fall back to 30%, which is what they were in recent years, the required revenue would rise to 2.2/0.3=$7.2 trillion. 

Keep in mind that the foregoing calculation does not even include revenue from SpaceX, the neoclouds, or Chinese AI companies. If one were to include those companies and others, we are potentially talking about AI needing to generate $10 trillion in annual sales to justify all the capex being thrown at it.

For reference, global spending on food (including restaurants) is around $10 trillion. Health care is about the same amount. The entire global software market is only $1.4 trillion. 

Clients can read the rest of the report here:

https://www.bcaresearch.com/reports/chief-economists-view-give-me-chastity-not-yet-19-08-2026/224466

Will Hyperscaler EBITDA Margins Continue To Rise?

Executive Summary

Top Takeaway: Wall Street analysts expect record-high earnings growth on top of record-high profit margins. While stocks could rise into year-end, the longer-term outlook for equities is unfavorable.

  • AI companies may need to generate $10 trillion per year in revenue to justify the capex that is being plowed into data centers. This is roughly equivalent to annual global spending on food or healthcare.
  • Fortunately for the AI trade, hardware shortages remain acute. As such, while the risks to stocks are tilted to the downside over a 12-month horizon, it is too early to tactically position for a bear market.
  • I would turn structurally more bullish on stocks if productivity growth were to accelerate. However, with US productivity growth clocking in at close to the 10-year average in Q2, so far there is little evidence of that.
  • One reason that oil prices have fallen from their peak is that rising crack spreads have reduced the demand for crude. That is not a particularly encouraging sign for the global economy.
  • Kevin Warsh's unwillingness to discuss the Fed's reaction function has increased uncertainty over the rates outlook, lifting bond yields in the process. Against the backdrop of a tightening labor market, yields are unlikely to fall much over the coming months.
  • By itself, the recent intervention to support the yen will probably be insufficient. More fundamental factors such as lower oil prices or weaker global growth will be necessary.
  • That said, the yen is extremely cheap by conventional valuation measures and has weakened more than one would have predicted based on changes in interest rate differentials. Thus, the long-term upside potential for the currency is large.

cf-indexnow: Submit URLs to search engines from ColdFusion

Mike's Notes

Useful. Filed away for future implementation.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > CFBreak
  • Home > Handbook > 

Last Updated

21/08/2026

cf-indexnow: Submit URLs to search engines from ColdFusion

By: James Mobeg
MyCFML: 19/08/2026

myCFML is the developer Blog of James Moberg, Senior Web Application Developer at SunStar Media. Featuring CFML-related articles and best practices.

IndexNow is an open protocol introduced by Microsoft Bing and Yandex in 2021. It lets a website notify search engines the moment a URL is added, changed, or removed instead of waiting for the next crawl. You POST a list of URLs along with a key that proves you control the host, and the submission is automatically shared with every participating engine: Bing, Yandex, Seznam, Naver, and Yep. (Google doesn't participate, but Bing results also feed DuckDuckGo, Yahoo, and others, so one ping still covers a lot of ground.)

I've published cf-indexnow, a CFC that implements the protocol for Adobe ColdFusion 2016+ and Lucee 5+. It's MIT licensed and I'm using it in production. IndexNow.cfc is the only required file:

indexNow = new IndexNow( host="www.example.com", key="yourindexnowkey" );
result = indexNow.submitUrl( "https://www.example.com/new-article" );
if ( !result.success ) {
writeLog( file="indexnow", text=result.message );
}

Network problems and API rejections never throw. Every submission returns a struct with success, the HTTP statusCode, a plain-English message, how many URLs were submitted, which input URLs were skipped, and the raw per-batch responses. Invalid constructor arguments do throw (with typed exceptions like IndexNow.InvalidKey), so configuration mistakes surface during development rather than in a production log.

submitUrls() accepts an array and automatically splits anything over 10,000 URLs into multiple POSTs, which is the protocol's per-request limit. submitSitemap() fetches a sitemap.xml, recurses into sitemap index files, and submits every URL it finds. In both cases, URLs that don't belong to the configured host are filtered out and reported in the result instead of being submitted, because a single foreign URL will get an entire batch rejected with a 422.

The key file

Ownership is proven with a plain text file at https://yourhost/{key}.txt containing nothing but the key. The component handles the lifecycle: generateKey() mints a spec-compliant key, writeKeyFile() writes the file to your webroot, and verifyKeyFile() fetches it over HTTP and confirms the content matches before you submit anything.

You don't need to store the key anywhere. I derive it from the hostname so every site gets a stable key with zero configuration:

indexNowKey = "indexnow-" & lcase( hash( cgi.server_name ) );

My scheduled task calls verifyKeyFile() first and regenerates the file if it's missing or wrong. It costs one HTTP request.

Only submit what changed

The spec asks you not to resubmit unchanged URLs, so you need to track state somewhere. I added a nullable IndexNowDate column to the content table. Inserts and edits clear the column; a scheduled task submits whatever is pending and stamps the date on success:


qry = queryExecute( "SELECT ID, 'https://#websiteHost#' + Permalink AS Permalink
FROM Posts WHERE IndexNowDate IS NULL", {}, {} );
batchResult = indexNow.submitUrls( urls=valueArray( qry, "Permalink" ) );
if ( batchResult.success ) {
queryExecute( "UPDATE Posts SET IndexNowDate = SYSDATETIME() WHERE ID IN (:ids)",
{ "ids": { "value": valueList( qry.ID ), "list": true, "cfsqltype": "cf_sql_integer" } }, {} );
}

Two behaviors worth knowing. Deleted pages should be resubmitted, not skipped: the spiders re-fetch the URL, see the 404 or 410, and drop it from the index. And when a URL gets a 301/302 redirect, submit the old URL too so the engines learn about the move.

A ColdFusion 2016 workaround

An IndexNow key is allowed to be all digits, and that's how I learned something I hadn't run into before. On ColdFusion 2016, serializeJSON() converts a numeric-looking string into a JSON number even when it's wrapped in toString() or javacast("string", ...). A key of "12345678" goes over the wire as "key":12345678 and the API rejects the submission with a 403. CF2016 is the only platform that does this. ColdFusion 2018+, Lucee, and BoxLang all keep the string quoted. (I verified this on ACF 2016.0.17 by asserting against the raw request body; if you round-trip through deserializeJSON() to test it, the coercion is invisible.)

The fix is Nathan Mische's JSONUtil, which serializes values by their actual underlying Java type. Rather than making it a hard dependency, it's a constructor option:

indexNow = new IndexNow( host="www.example.com", key="12345678", useJSONUtil=true );

The default uses native serializeJSON(), which behaves correctly on every current engine. I enable useJSONUtil anyway. It's a little slower, but JSONUtil is stricter, which I like: deserializeJSON( JSONvar=body, strictMapping=true ) throws when the JSON contains duplicate keys (BoxLang behaves the same way, while Adobe ColdFusion silently accepts them), and it avoids another long-standing Adobe frustration when debugging or transforming data: every ACF version re-orders keys alphabetically when deserializing, while Lucee and BoxLang honor the original key order.

Testing

The repo includes a framework-free test harness: 38 tests that run against a local mock endpoint, so the suite never contacts the real API. It's verified green on Adobe ColdFusion 2016 and Lucee 5.4. There's also a demo page that exercises the whole flow against the mock, plus a localhost-only smoke test page for a one-time check against the live endpoint with a real key.

Grab it at github.com/JamoCA/cf-indexnow. If you hit an engine quirk I missed, open an issue and let me know.

IT-ontology. one more definition

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part six: A post by Michael DeBellis that criticises something John F Sowa wrote on the Ontolog Forum and James Lee Stakelum's views on SGF. I added the names of people quoted to make the robust exchange of views clearer for me.

Resources

References

  • A Universal Moral Grammar (UMG) Ontology, Michael DeBellis, 2018.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

20/08/2026

IT-ontology. one more definition

By: Michael DeBellis
Ontolog Forum: 19/08/2026

Michael DeBellis is a Semantic Web and AI consultant and researcher with over 40 years of experience in industry and academia. He began designing ontologies in the early 1980s while building expert systems for Accenture and later worked as a researcher at USC’s Information Sciences Institute (ISI), where he used Loom — a direct predecessor to the Web Ontology Language (OWL). Throughout his career at firms including Deloitte, Accenture, and ThoughtWorks, he has focused on applying advanced technology to real-world enterprise challenges. His work emphasizes the practical integration of Semantic Knowledge Graphs into complex systems, highlighting the importance of user requirements, legacy data, and enterprise architecture over purely theoretical modeling. He has published and presented internationally on a broad range of topics across multiple domains​.

John F Sowa

Protégé was designed to use OWL,  which is dead end technology.  There is a huge amount of obsolete OWL software, and it must be supported indefinitely.  But new applications should never be based on OWL.  

Michael DeBellis

That's a pretty strong statement and I didn't see anything strong enough to support such a statement in the linked to article: https://medium.com/@JamesStakelum/why-the-triple-is-the-wrong-grain-1cad99e136f4

For example he says: 

James Lee Stakelum

Failure 1: The triple cannot represent an event as a whole.

RDF/OWL representation (five triples):

:Beethoven rdf:type :Composer .
:NinthSymphony rdf:type :Symphony .
:Beethoven :composed :NinthSymphony .
:NinthSymphony :composedIn :Vienna .
:NinthSymphony :composedInYear "1824" .

Michael DeBellis

And contrasts that with: 

James Lee Stakelum

SGF provides the Synapse — a hub‑and‑spoke structure. The verb is the hub (the VerbHub). Participants attach through exactly 15 fixed semantic roles.

Synapse: s1
VerbHub: compose
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

One object. The VerbHub is not an edge label. The event is whole. 

Michael DeBellis

You could do that with OWL too. Create a subclass of Event called Compose:

Event: Compose_Ninth_Symphony
rdf:type: Compose (subclass of Event)
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

I had a model exactly like this, including using a property called has_patient for Agents that were impacted by an Event, in the first OWL ontology I ever wrote about called the Universal Moral Grammar. https://www.academia.edu/53542647/A_Universal_Moral_Grammar_UMG_Ontology  

His argument about not being able to define provenance also seemed weak:

James Lee Stakelum

Failure 2: The triple cannot carry its own provenance.

:Beethoven :composed :NinthSymphony .

This triple is structurally identical whether it came from a scholarly biography or a random comment. Named graphs are optional — provenance can be stripped in transit.

This is a limitation of OWL compared to Property Graphs if we are just talking about properties. In OWL there is no way to associate metadata with a specific triple because the triple is implicit, there is no data structure for each instance of a relation. But he actually describes a solution to this when he says "Named graphs are optional — provenance can be stripped in transit." This is one thing I've come to realize in the last few years going from prototypes to actual systems integrated with real data: named subgraphs are essential for many use cases of large RDF graphs in the real world. E.g., in Stardog they aren't optional. You have to put certain kind of data such as data inferred by the reasoner, into specific sub-graphs. 

Michael DeBellis

I agree, one obvious use for subgraphs is for metadata, another is for defining security and encapsulation boundaries. But the fact that they are optional hardly seems like a reason to just completely throw OWL away. You can just make them non-optional with standards the way Stardog does. And you can also deal with the property problem by just reifying the property. I.e., turn a property into a class so when you create an instance of the relation you create an instance of the class. This pattern is much older than OWL. It's one of the most standard patterns used in OOP.  I imagine most readers know it well but in case you don't: https://www.w3.org/TR/swbp-n-aryRelations/

In this example, we already did the reification in the previous case when we created a subclass of Event called Compose. We could use that to solve the provenance problem as well: 

Event: Compose_Ninth_Symphony
rdf:type: Compose (subclass of Event)
HAS_AGENT: Beethoven
HAS_PATIENT: Ninth_Symphony
HAS_LOCATION: Vienna
HAS_TIME: 1824

has_source: https://en.wikipedia.org/wiki/Symphony_No._9_(Beethoven)

He also says:

James Lee Stakelum

Failure 4: The triple cannot carry its own grounding.

The URI :Beethoven points to a document, not a concept. Is it the composer, the dog, the crater? 

Michael DeBellis

That's not true. Just because it is an IRI doesn't mean it points to a document. He's confusing IRIs and URLs. 

And his solution is:

James Lee Stakelum

The triple cannot carry its own disambiguation. Therefore every identifier must carry its own sense‑level distinction and trace to a shared foundation.

SGF provides the Canonical ID: en.beethoven.ludwig_van_beethoven.person.core. The microgloss ludwig_van_beethoven distinguishes this sense from others. Every Canonical ID has a finite IS‑A path to the Prime Registry — approximately 65 irreducible semantic primes (DO, HAPPEN, SOMEONE, SOMETHING, GOOD, BAD, etc.). Paths terminate at primes. No infinite regress.

Michael DeBellis

That kind of universal ontology for the entire enterprise goes against the best thinking  from people like Dehghani, Fowler, and Evans about Domain Driven Design (the state of the art for Microservice design) and Data Mesh (the state of the art for Data Products which are the microservice equivalent for data). One of the core ideas behind both is that one model for the entire enterprise is an anti-pattern. Not to mention I can't imagine how that kind of highly centralized model is going to work with petabytes of data. It goes against one of the core directions that I see in modern software development: adoption of truly distributed programming. It's why functional programming is finally no longer only for nerds because functional programs (e.g., the Map-Reduce algorithm used with Apache Hadoop and Spark) are great at dealing with highly distributed data. 

But I have a feeling we may be debating apples and oranges. I'm talking about what people building systems that have to deal with petabytes of data and integrate with LLMs should use now and I think OWL and Semantic Web technology make a lot of sense. I mentioned this before but it's worth repeating: the last couple of years I read several books by thought leaders about managing enterprise data: Strengholt, Dehghani, Olesen-Bagneux, and all of them have requirements that are virtually a perfect match for Semantic Web technology: 

  • Use URLs for persistent IDs
  • Use standards
  • Explicit representation of metadata (includes semantic metadata)
  • Graph models and databases
  • Implementation-independent domain models
  • Active metadata (e.g., automated reasoning)
  • Powerful and flexible search

There are also real world examples that are being built. One of the issues with tech like this is that the people who use it don't want to talk about it because they see it as a competitive advantage but I can say from first hand experience it is being used at several tech leaders in the industry. One company that will talk about it is a German company that makes parts for modern cars. They built a Semantic Data Catalog using OWL, RDF, and standard W3C vocabularies such as DCAT and PROV. A paper from those guys is attached. 

Getting back to whether we're talking research or real world. Here is a list of the most popular database vendors right now: https://db-engines.com/en/ranking  

It's kind of depressing how Neo4j is so far above the nearest RDF triplestore. But at least all the major RDF triplestores are on the page. I didn't see a single product that uses The Symbol Grounding Framework (SGF) in that list. 

Michael

https://www.michaeldebellis.com/blog

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

Mike's Notes

An excellent ACM article clearly explains how AI is making programming differently difficult. I agree with all the conclusions based on my experience. In my case, I have found that using AI has made it much easier to use my visual way of thinking to design complex system architecture, rather than memorising lots of code syntax. The AI creates the syntax from instructions I give it, driven by architecture decisions rather than code-level details.

These changes are great: they provide more opportunity and an order of magnitude more productivity, allowing more time to read, think and discuss. 10 minutes with AI generates what previously took a week to build.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

19/08/2026

AI Didn’t Make Programming Easier. It Just Made It Differently Difficult

By: Jeremy Osborn
Communications of the ACM: 14/07/2026

Jeremy Osborn (jeremy.osborn@gmail.com) is a technology leader whose work spans software, governance, sustainability, and strategy.

The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

...

Opinion

For decades, empirical research has shown that programming is a demanding cognitive activity: Developers rely on working memory, long-term recall, and complex mental models to manipulate interacting abstractions such as control flow, data structures, and the structural design of software. This classical model frequently positioned memory and recall as both the central enablers of, and bottlenecks in, software development.

Today’s AI-powered coding assistants are changing that. These tools function as external memory systems, offloading syntax recall, boilerplate generation, and API usage from human to machine memory. As memory demands lessen, reasoning, architectural comprehension, judgment, and code-structure awareness are becoming comparatively more important.

Thus “knowing how to program” is being fundamentally redefined, but not in ways that make programming easier or that devalue the programmer. This article describes four major shifts in how programming work is changing:

  1. The field is opening to new practitioners.
  2. The work is becoming differently difficult.
  3. Education is transforming.
  4. The programmer’s role is evolving from knowledge vessel to orchestrating agent.

Together, these shifts suggest that AI is not eroding the cognitive substance of programming but relocating it—making different skills matter more and creating new forms of difficulty even as old barriers fall.

Programming as High-Memory Work

For most of the history of software development, researchers found that programming relied on a combination of reasoning ability, working memory capacity, and long-term memory recall. Brooks described programming as a cognitive process that depends on maintaining multiple interacting abstractions. [4] Pennington then demonstrated that programmers rely on complex mental models of control flow and data flow to design, understand, and modify code. [6] Studies have shown that these mental models exist in the mind as abstractions, are maintained at high cognitive cost, and are relatively fragile. They break down easily under conditions of context switching and are costly to rebuild in cognitive terms if they are not documented.

Today, however, AI coding assistants are reshaping this traditionally onerous cognitive landscape. Developers now have access to external memory systems capable of generating code, retrieving syntax, reconstructing context, and remembering and regenerating variants of previous mental constructs. This does not eliminate the need to think. But it does shift which cognitive skills are becoming most relevant for programmers.

Working memory and long-term recall.  Working memory is the limited-capacity system that supports temporary storage and manipulation of discrete blocks of information, as formalized by Baddeley and Hitch. [2] Long-term memory, conversely, serves as the repository of consolidated knowledge, including declarative information such as syntax and architectural concepts, and procedural knowledge like coding idioms and problem-solving schemas.

Programming has traditionally relied heavily on both. Soloway, Bonar, and Ehrlich found that programmers rely on internal cognitive preferences, [9] presumably based on experience and retrieved from long-term memory, to structure their approach to iterations. For example, when a loop construct matched the programmer’s natural plan, correctness increased dramatically. This suggests that programming has historically been guided not just by syntax knowledge but by the formation and execution of internal cognitive preferences retrieved from memory and expressed as mental models through design choices. Siegmund et al. used fMRI to show that code comprehension activates networks associated with working memory, attention, and language processing, [8] providing physiological evidence that understanding complex programming tasks is a resource-intensive cognitive task at the neurological level.

Theories of AI as an external memory resource.  AI coding assistants alter this cognitive landscape by acting as external memory and cognition. This aligns with Hutchins’ theory of distributed cognition, which argued that cognitive systems often extend beyond the individual to include the external environment, [5] which can extend and enhance individual cognition.

Alternate theories complement distributed cognition. Cognitive load theory (CLT) holds that AI tools can reduce extraneous load, which is the memory overhead of recalling syntax and boilerplate, thereby freeing working memory for intrinsic, high-level reasoning. The Extended Mind Hypothesis (EMH) goes further by focusing on the individual: If an AI assistant becomes reliably available, habitually used, and trusted, it can function as an integrated component of the programmer’s cognitive architecture rather than as an external tool. Under this view, the AI becomes part of the thinking process itself, shaping reasoning, decision making, and the effects of cognitive effort.

Barke, James, and Polikarpova [3] showed that developers commonly use Copilot to offload low-level work, such as typing boilerplate, recalling API details, and looking up unfamiliar syntax, while shifting effort toward validating and integrating the generated code. These findings collectively support the view that AI is not merely a faster search engine; it is at least partly an integrated extension of human cognitive architecture.

What AI removes and what it does not.  Thus, AI fundamentally changes the costs associated with imperfect memory, effectively reducing the penalty for imperfect recall. A developer can successfully request a common API usage pattern without precise internal recall or retrieve complex syntax without relying on working-memory-intensive reconstruction. This capacity directly reduces the dependency on the rapid retrieval of specific, low-level knowledge from long-term memory, mitigating the cognitive bottleneck previously identified.

However, while AI-assisted programming tools can accelerate routine development tasks, they do not eliminate the need for human oversight, particularly when work requires conceptual reasoning rather than surface-level code manipulation. Every programmer knows AI can produce code that is syntactically correct yet semantically and subjectively flawed, meaning developers must still understand program structure well enough to detect errors, evaluate coding suggestions critically, and ask the necessary “why” and “why not” questions about causal behavior.

Shihab et al. found that students using GitHub Copilot completed brownfield tasks substantially faster and with more solution progress, but in exit interviews many reported concerns about not fully understanding how or why Copilot’s suggestions worked, and the authors call for pedagogical approaches that leverage Copilot’s benefits while fostering comprehension. [7] Alanazi et al., in a meta-analysis of controlled studies of tools such as ChatGPT and Copilot in programming education, reported that while AI assistance improves task performance and efficiency, it offers only small and statistically unstable gains in learning success and ease of understanding. [1]

Taken together, these findings support the view that architectural reasoning, impact analysis, and long-term system maintenance cannot be offloaded to AI. They depend on deep, structural understanding of the codebase that remains the programmer’s responsibility. So, while AI may extend cognition and make certain programming tasks more efficient, thereby improving the productivity of trained developers, critical tasks such as debugging, refactoring, and systems analysis still require expertise and comprehension, and rely heavily on internal mental models that allow programmers to simulate execution and infer complex cause-and-effect paths within a codebase.

This marks a significant cognitive reorganization: Memory becomes a shared resource spanning human and machine; programming becomes less about what the developer can hold and manipulate in their mind and more about how clearly they can think at multiple scales when creating and ordering a complex logical system. Studies confirm that stable mental models of a codebase are essential for navigation and reasoning. Therefore, if developers outsource too much thinking to AI, those internal models can weaken. AI thus shifts cognitive load rather than removing it and speeds up writing code but increases the time spent checking and validating it.

In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”). This shift from recall-based to judgment-based programming represents the fundamental cognitive transformation at the heart of AI-assisted development. Where traditional programming demanded that developers maintain vast internal libraries of syntax, patterns, and idioms, AI-enabled programming demands instead they maintain robust evaluative frameworks for assessing correctness, coherence, and appropriateness. The cognitive burden has not disappeared—it has relocated from retrieval to reasoning.

Programming as Hybrid Cognitive Systems Work

The emerging reality is not that AI replaces the programmer, but that it becomes a second cognitive engine running in parallel. The machine surfaces patterns, stitches together APIs, retrieves forgotten syntax, and drafts first-pass solutions at a speed that reduces low-level recall bottlenecks but can also increase the burden of evaluation. The human, in turn, becomes less a conductor of keystrokes and more a shaper of intent: checking, interpreting, integrating, synthesizing, validating, reorganizing, discarding, editing, and ultimately giving structure and purpose to what the system supplies. It resembles what has already happened in medicine: Diagnostic tools lowered the burden of memorizing obscure clinical details but raised the stakes for interpretation, judgment, and error detection. Expertise became less about recall and more about reasoning.

Understanding this hybrid arrangement helps explain why AI makes programming differently difficult rather than simply easier. The difficulty has not been eliminated; it has been redistributed across a new cognitive architecture that spans human and machine. This redistribution creates new challenges even as it removes old ones.

As AI continues to function primarily as an externalized memory and a code-transformation layer, four major shifts are already visible:

  1. First, the field will open. Many who once would have bounced off the sheer cognitive overhead of memorizing libraries, syntax variations, or error-handling idioms will now find a workable entry path. The bottleneck of recall shrinks, making programming more accessible to people who might previously have struggled with syntax, library details, or unfamiliar idioms, while placing greater emphasis on problem decomposition, systems reasoning, and the ability to evaluate generated code. However, this accessibility comes with a paradox: While the barrier to producing code lowers, the barrier to producing good code may actually rise, as judgment becomes more critical and harder to develop than recall ever was.
  2. Second, the work does not become simpler, only differently difficult. Conceptual clarity, decomposition, debugging, and architectural foresight still demand effort, and perhaps more of it. The challenge moves up a level. Where novice programmers once struggled primarily with syntax errors and API usage, they now struggle with evaluating whether AI-generated solutions are appropriate, maintainable, and aligned with broader system constraints. This represents a more sophisticated form of difficulty, one that requires deeper understanding of software-engineering principles rather than surface-level language features.
  3. Third, education will shift. We will teach fewer people to memorize syntax and more to think in complex systems. The curriculum bends toward architecture, interface design, state management, failure modes, constraint negotiation, test construction, security, and long-term maintainability. Code becomes only one representation of thought among many overlapping ones. Developers must still possess the skills to analyze, adapt, and modify what AI produces, perhaps even more so than before.
  4. Fourth and most importantly, the programmer remains essential. Not as a vessel of knowledge but as the orchestrating agent who understands the parts and how they fit together, maintains the integrity of the system, and who decides what matters. This shift has profound implications for how we understand programming expertise. The most capable developers of this new era will not be those who type the fastest or remember the most, but those who can hold deep mental models while offloading everything that interferes with that. They will combine strong systems reasoning with AI-augmented recall and will treat the model almost like a cognitive prosthetic: useful, fast, but incapable of finally determining subjective-semantic correctness or coherence.

Conclusion

Taken together, these four shifts suggest AI is not eroding the cognitive substance of programming but relocating it. As external memory becomes abundant and code generation cheap, the value of the programmer moves toward interpretation, structural reasoning, and judgment. The future of software development will belong to those who can think clearly at scale, maintain durable mental models amid rapid change, and integrate machine-generated output into human-directed intent.

AI does not, therefore, diminish the craft; it widens it, deepens it, and makes more of the work explicitly intellectual. The work becomes differently difficult because it demands more sophisticated forms of expertise: judgment over recall, architecture over syntax, orchestration over implementation. These are not easier skills to develop or demonstrate, they are simply different ones, and perhaps ultimately more demanding.

References

1. Alanazi, M., Soh, B., Samra, H., and Li, A. The influence of artificial intelligence tools on learning outcomes in computer programming: A systematic review and meta-analysis. Computers 14, 5 (2025), 185.

2. Baddeley, A.D. and Hitch, G. Working memory. In The Psychology of Learning and Motivation 8, Academic Press. G.H. Bower (Ed.) (1974), 47–89.

3. Barke, S., James, M.B., and Polikarpova, N. Grounded Copilot: How programmers interact with code-generating models. In Proceedings of the ACM on Programming Languages 7, Article 78 (2023), 85–111.

4. Brooks, R.E. Towards a theory of the cognitive processes in computer programming. Intern. J. Man-Machine Studies 9, 6 (1977), 737-751.

5. Hutchins, E. Cognition in the Wild. MIT Press (1995).

6. Pennington, N. Stimulus structures and mental representations in expert comprehension of computer programs. Cognitive Psychology 19, 3 (1987), 295–341.

7. Shihab, M.I.H. et al. The effects of GitHub Copilot on computing students’ programming effectiveness, efficiency, and processes in brownfield programming tasks. In Proceedings of the ACM Conf. Inter. Computing Education Research (2025), 407–420.

8. Siegmund, J. et al. Understanding source code with functional magnetic resonance imaging. In Proceedings of the 36th Annual Intern. Conf. Software Engineering, ACM (2014), 378–389.

9. Soloway, E., Bonar, J., and Ehrlich, K. Cognitive strategies and looping constructs: An empirical study. Commun. ACM 26, 11 (1983), 853–860. 

What is SGF?

Mike's Notes

This is part of a series of thoughtful opinions about using Ontology in software information systems.

Pipi has an existing BORO Engine (bor) (inspired by Chris Partridge's book "Business Objects: Re-engineering for Re-use"), but it runs in reverse: it imports triples to extract entities and relationships, then uses them to build reference relational databases for back-end industry workspaces.

Part five: An article by James Lee Stakelum that summarises SGF. A PDF is also available.

Resources

References

  • SGF: The Symbol Grounding Framework, James Lee Stakelum. GitHub. 2026.

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/08/2026

What is SGF?

By: James Lee Stakelum
Medium: 11/08/2026

I'm deep into building an architecture for structured knowledge, and using AI to create cinematic quality movies.


The SGF (Symbol Grounding Framework) project is moving fast!

Six volumes have been published on Amazon. The GitHub repository contains formal RFCs, reference implementations, and numerous essays. The architecture has grown from a single insight about dictionaries into a seven-layer stack with three core components: a governance language called ‘Omega’ that enforces what the machine CAN, MAY, and DO; a machine-to-machine protocol called HFF that lets machines communicate with zero prior integration; and an operating system for autonomous systems that has a constitution, the ability to mint new laws — as long as they are constitutional — and sovereignty: the power to refuse outside instructions that violate its own rules.

But there’s a problem: the information about SGF is spread across several books, RFCs, published code, and essays. If you want to understand “what is SGF?” you currently need to read six books and several thousand lines of specification.

I’m working on a new book that puts everything into one book, but decided as an interim solution to consolidate the big picture into a single white paper. I will provide the link to the white paper below.

But first, let me give you the overview — the five-minute talk I would give if I were standing in front of a room describing SGF.

...

SGF is a deterministic Semantic Infrastructure. It lives in the broader space of Verifiable Knowledge Infrastructure — systems that can represent meaning, verify it, trace it to its source, and govern actions based on it.

First, let me give you the back-story.

When I first started the SGF project, began by writing code to transform prose from textual documents (PDFs, wikipedia articles, etc) into a structured format and storing it in a knowledge graph, so that human knowledge could be stored in a structured format that LLMs could use, instead of RAG, so it would be easily inspectable and verifiable (you dont normally see where an LLM got its facts), and be tagged with provenance showing where each fact came from, etc.

I began searching for a structure that could hold meaning at the grain of a clause. A sentence might span multiple clauses and therefore is not the right grain. A RDF triplet is too small for my intended purposes for many reasons I have explained elsewhere in SGF essays.

Thematic role theory was a natural fit. Thematic role theory deconstructs a clause into a core predicate and a set of universal semantic roles that define how participants in the clause relate to the action, independent of surface grammar. Rather than relying solely on grammatical labels like subject or object, the framework maps sentence participants to specific semantic functions — such as agents, patients, instruments, and goals — governed by the intrinsic argument structure of the verb.

Using thematic role theory, I arrived at a hub-and-spoke structure — one verb, its participants, their roles — without shattering it across multiple fragments. That search led to an architecture.


First: a schema and grammar for structured knowledge.

Most knowledge representations use triples — subject-predicate-object. Triples fragment events. An event that involves an agent, a patient, a time, a location, an instrument, and a reason shatters across multiple triples, losing the structural integrity of the original claim.

SGF uses a Synapse — a verb hub with exactly 15 fixed thematic roles. These roles come from 50 years of cross-linguistic research in thematic role theory — Fillmore, Jackendoff, FrameNet. They are not arbitrary. They are the discovered universal slots through which participants attach to events.

Every clause compiles into exactly one Synapse. No event fragments. The roles are closed, which means integration cost drops from N² to N. An engineer does not need to learn a new relationship vocabulary for each domain. The same 15 roles serve contracts, medical guidelines, military operation orders, and manufacturing specifications.

Every Synapse carries its provenance — source document, section, sentence, offset. Every Synapse carries its epistemic status — is this a core definition, a sourced observation, an inferred conclusion, or a ghost that the system knows exists but cannot yet resolve? SGF does not decide who is telling the truth. It records what was said, by whom, and with what source. Truth is resolved at query time, not ingestion time.

I’m a bit embarrased to say that early in the SGF project, I naively assumed all thought was atomic. Like “Ludwig van Beethoven was born in 1770” is an example of what I would consider an atomic thought. It can stand alone, as long as you can tether each term to a dictionary that tells you what each term in that sentence means. But the recipe to bake a chocolate cake is not atomic. Each step is an atom, and to extend the metaphor, I needed linking mechanisms to join the atoms in meaningful ways. That led me to linking types.

Synapses compose into larger structures via 8 link types — CAUSES, SUPPORTS, CONTRADICTS, PRECEDES, DEPENDS_ON, and others. A recipe, a contract, a military operation order is molecular, not atomic.

And, furthermore, these larger structure are composable into even larger structures.

...

Second: a recipe for bootstrapping a shared dictionary — the dictionary itself is not mandatory, but the network effects are real.

Language is a lossless compression algorithm. We say “wagon” instead of saying “a container mounted to an axle with wheels and a hitch so it can be pulled.” We compress complex cognitive scripts into single tokens because the serial interface of speech is slow. Compression lets us transmit meaning faster than we could decompress it.

But compression without decompression is just noise. Most dictionaries fail at decompression because they are lossy — they define complex words using other complex words. Pail equals bucket. Bucket equals pail. The chain never terminates.

SGF’s approach is different. The architecture requires that two parties agree on a shared dictionary. Any dictionary. Your organization’s existing ontology. An industry-standard taxonomy. A custom-built lexicon. What matters is that both parties point to the same reference and agree that when they use a Canonical ID from that dictionary, they mean the same thing.

If you already have a dictionary, use yours. The architecture does not care which dictionary you choose. It cares that you agree on one.

What SGF provides as a convenience is the Synapedia — a recipe for bootstrapping a very large dictionary from open sources. WordNet for core vocabulary. Wiktionary for long-tail coverage across hundreds of languages. Wikipedia for world knowledge. The bootstrap scripts are on GitHub. Given the same snapshot and pipeline, any party can rebuild a conformant Synapedia in hours and verify its content hashes.

The Synapedia is a design pattern template. It shows you how to structure a shared dictionary with Canonical IDs, microglosses, IS_A chains, polyhierarchy, and prime grounding. You can follow the same pattern with your own dictionary.

There is a network effect, and it is real. Like the fax machine, the value of a shared dictionary compounds with each additional party that agrees to use it. The first integration takes time. The tenth is faster. The hundredth is nearly automatic.

What is mandatory is the Canonical ID — the structured identifier that carries disambiguating meaning in the ID itself. en.bank.financial_institution.noun.core. Not a UUID. Not a random string. The language, the lemma, the microgloss, the part of speech, the namespace — all in the ID. Two systems that have never communicated can resolve this ID to the same sense without a prior agreement.

And what both parties must have is their own private lexicon — an in-house dictionary for the terms unique to their world. Internal product codes. Organizational jargon. These live in the private lexicon, not in the shared dictionary. When they cross a boundary, the message includes a dictionary segment for each private term, tethered to the shared dictionary via binary ontological links.

The relevant links include:

  • IS_A — connects a concept to its parent concept. A water_pump IS_A pump.
  • INSTANCE_OF — connects a specific individual to its concept class. A pump with serial number ABC123 INSTANCE_OF water_pump.
  • HAS_PART, HAS_ATTRIBUTE, SAME_AS and others.

IS_A and INSTANCE_OF are distinct. IS_A operates between concepts. INSTANCE_OF operates between an instance and a concept. Ontologists care about this distinction, and they are right to care.

Not all prose is suitable for this. Joyce’s Ulysses will produce more GapReports than Synapses — and that is by design. The system does not pretend it can parse everything.

At the bottom of every IS_A chain: 65 semantic primes from the Natural Semantic Metalanguage. Irreducible concepts like SOMEONE, SOMETHING, DO, HAPPEN, GOOD, BAD, THINK, FEEL, BODY. If a term cannot reach a prime — if it is a hallucination, a fabrication, a term that has no route to shared ground — the system returns UNKNOWN. It does not fabricate. It does not guess. It reports the gap.

...

A note on how this relates to existing ontology standards.

This is the dual-axis alignment, and it is one of the most important things to understand about SGF.

BFO and CCO — the ontology standards the DoD and Intelligence Community have adopted — guarantee formal consistency. They answer: “Does this classification respect our axioms?” They do not answer: “Does this concept correspond to anything real?” An LLM might fabricate a “chronospatial dampening array,” BFO might classify it as Artifact → Independent Continuant, every axiom satisfied, and the system accepts a fabrication with mathematical certainty.

SGF operates on two separate axes to address this.

Axis 1 — The semantic axis. This handles human language — cognition, intent, compression, decompression, metaphor, social constructs. It is grounded in 65 NSM primes. Its purpose is anti-hallucination: every term must trace an IS_A chain back to bedrock or the system returns UNKNOWN. This axis answers: “Does this concept correspond to anything we can ground in shared meaning?”

Axis 2 — The ontological axis. This handles institutional compliance — BFO, CCO, audit trails, export to formal standards. Its purpose is consistency across systems: when an entity leaves SGF’s internal runtime and enters the institutional record, it must speak the language that review boards, regulators, and partner systems already understand. This axis answers: “Does this concept satisfy our formal classification axioms?”

These are separate axes because meaning and existence are different things, modeled by different frameworks, serving different purposes. No single framework can serve both. That is why SGF keeps them on separate axes, connected by a deterministic bridge that translates without conflating.

The bridge between them is a set of transformation rules. The semantic runtime preserves terms as they appear in human language. At the export boundary, those terms are mapped to their closest BFO categories, with documentation annotations where the mapping is imperfect. The bridge is one-directional by default — from the semantic runtime outward to the institutional record — because the ingestion pipeline must remain open to human language, while the export boundary must speak the language of formal ontology.

I want to be clear about where SGF currently stands. Formal BFO certification is not an active project focus today. The current focus is engineering the architecture, producing working code, and finding implementation partners. But the architecture is designed for this alignment from the ground up.

The mapping is not always clean. Consider a hole. NSM says a hole is a THING — it has location, shape, it can be created and destroyed. Language treats holes as entities. BFO says a hole is not an Independent Continuant — it is a fiat surface, a dependent entity. SGF does not hide this tension. It preserves the term on the semantic axis and maps to the closest category on the ontological axis, with documentation explaining the discrepancy.

BFO ensures consistency. NSM ensures truth. Together, they provide what neither can provide alone.

...

Third: a protocol for machine-to-machine communication that requires zero prior integration.

Most integrations are pairwise. Every pair of systems requires bespoke ontology mapping, data format alignment, and policy negotiation. The cost scales as N².

SGF’s protocol layer — HFF (Honest Fact Forwarding) and AFP (Act Framing Protocol) — lets two machines that have never met exchange meaning on first contact. Both share a dictionary. The sender brings its own definitions for terms not in the shared dictionary, tethered to it via binary links. The receiver follows the links back to shared ground.

Why does AFP matter? A robot that parses “Can you pass the salt?” as a yes/no question about physical capability, confirms it can, and then does nothing — that is the failure AFP prevents. AFP declares what act the message is performing. Thirteen act types — INFORM, COMMAND, PROMISE, REFUSE, CONFIRM, ERROR, and others — tell the receiver whether this is a statement, a request, an order, or a promise. The same payload wrapped in INFORM versus COMMAND goes through completely different authority gates.

Every message passes through five integrity gates: schema validation, hash verification, signature verification, freshness check, and lexicon hydration. A message that fails any gate is rejected. A message that passes all five is a candidate for admission — not an instruction to obey. The receiver remains sovereign.

...

Once I had the dictionary, I realised… Each layer exposed the absence of the next.

This is how the architecture grew. I started with the grammar and the dictionary. Once I had those, I realized two machines that wanted to exchange this structured meaning needed a protocol. That led to HFF and AFP. Then I realized governance could not be a prose prompt. That led to Omega. Then I realized the system needed a way to learn from its own experience. That led to Wisdom Harvesting.

Each layer exposed the absence of the next. The architecture was not designed in a single pass. It was discovered through building.

...

Fourth: an operating system with a small stable kernel, continuous learning of wisdom, sovereignty, and the ability to mint new laws.

Knowing what a message means is not the same as knowing whether the requested action is permitted.

Omega is a governance language with exactly 13 primitives. It is non-Turing-complete. It is compiled at load time. It is fail-closed — no matching rule means DENY. CANMAYDO is enforced as a structural constraint, not a suggestion. A machine that can parse a command cannot execute it unless a compiled rule explicitly permits it.

The Event Horizon separates probabilistic reasoning from deterministic action. The LLM proposes. The governance layer decides. The actuator executes only when the governance layer says ALLOW. The kernel — small, deterministic, never-changing — mediates the crossing. It cannot be overridden at runtime.

Wisdom Harvesting sits above the stack, monitoring every interaction, extracting cross-domain principles, and storing them in a retrievable corpus. The kernel does not modify itself. It accumulates wisdom. A rule learned from a database connection timeout — “release finite shared resources after use” — is surfaced when a mutex deadlock occurs in an entirely different context months later.

The machine has sovereignty. It can refuse a command that violates its constitution. It can mint new laws within constitutional constraints, adapting to novel situations that were not anticipated at design time.

...

And it compounds.

This part matters more than I have let on so far.

Most systems do not learn. They are loaded with knowledge at deployment, and that is all they ever know. SGF is different. Above the stack sits a Wisdom Harvesting pipeline that monitors every interaction — every GapReport, every governance decision, every alignment failure, every success — and extracts cross-domain principles from them.

A rule learned from a database connection timeout — “release finite shared resources after use” — is surfaced months later when a mutex deadlock occurs in an entirely different context. A lesson from aerospace manufacturing — “when a provenance chain has been incomplete for two consecutive batches, escalate verification depth” — appears in an industrial robotics setting where the system has never encountered aerospace data.

The kernel never changes. It stays small, deterministic, certifiable. The wisdom grows above it, accumulating with every operation, every failure, every success. The system gets better with use.

This is not a feature. It is a different category of system.

...

Design patterns have emerged from using this architecture.

SOAM aligns Synapse Trees node by node across five dimensions — branch matching, concept matching, constraint comparison, frame alignment, and modality alignment. Every failure produces a GapReport. The Decider produces one of five outcomes: ACCEPT, REJECT, CONDITIONAL, CLARIFY, or ESCALATE. The system never guesses.

The Returns Pattern lets a warehouse identify a returned part that has no packaging and no SKU label. The system uses visual features and verbal descriptions, aligning against the catalog through the same depth hierarchy that serves specification verification.

The Privacy-Preserving Verification Pattern lets a contractor prove a component meets a specification by exporting an 86-character fingerprint and pass/fail flags. No proprietary data leaves the air gap.

Each pattern is a reusable solution to a problem that previously required bespoke engineering.

...

Every formalism leaves a remainder. SGF does not claim to have closed the gap between structure and meaning. It provides mechanisms for inhabiting that gap honestly.

The GapReport is not a failure mode. It is a design feature. When the system cannot ground a term, assign a role, resolve a pronoun, or classify a clause, it says so. It does not fabricate. It does not guess. It produces a structured report naming exactly what is missing.

A court reporter does not decide who is telling the truth. The court reporter records what was said. SGF is that court reporter for machine meaning.

...

The full white paper covers all of this in depth.

It describes the complete seven-layer stack, the dual-axis ontological alignment, the formal evaluator model for Omega, the Wisdom Harvesting pipeline, the convergence argument, the honest claims, and the implementation status.

The PDF and Markdown versions are on GitHub:

The repository also contains numerous essays, the RFCs, and working code for bootstrapping the shared dictionary and for transforming prose into structured format.

I’m moving as fast as I can, and there’s more code that still needs to be written. The code I’ve written is intended to help get you started. You may want code in your own language of choice. I purposely wrote the RFCs in a form that, mostly, can be compiled into code of your preference — Python, C++, Java, Rust.

A closing thought.

I started with some simple questions: can we build a decompression mapping for language? Can we reverse the compression that turns a container mounted to an axle with wheels and a hitch into ‘wagon’? Can we build a process that compiles prose into a structured format, with each term tethered to a shared dictionary?

The answers turned out to be yes. And that unlocked an operating system — a system that can represent meaning deterministically, share it across trust boundaries with zero prior integration, govern its own actions through a written constitution, and compound its expertise over time.

The architecture is open. The code is Apache 2.0. The standards are published as RFCs.

The question is not whether this is possible. The question is what we will build with it.