DEV Community: Nelson Amaya

AI Governance Must Be Runtime and Deterministic

Nelson Amaya — Sat, 12 Sep 2026 12:00:10 +0000

I follow the AI governance news closely, and recently I have been hearing a lot of chatter about AI governance harnesses. I think the enterprise industry is slowly waking up and realizing that Large Language Models (LLMs) need a cage.

I actually like the idea of thinking about AI governance in terms of harnesses. SAFi is technically a harness itself, but the way the rest of the industry is approaching the problem is completely backward.

Take a tool like Claude Code. It is an agentic harness, it has a software layer built around the LLM to give it tools, memory, and execution capability. But in that setup, the LLM is still the star of the show. It executes and makes decisions on its own.

SAFi, on the other hand, makes the LLM a substrate of its thinking process. In SAFi, the LLM is just another step in the execution pipeline. The LLM is not in charge; it is simply a component in the loop.

Because the LLM is the reasoning module, it can propose an action. But that action must first be approved by an independent module. That approval module is pure Python, it is completely blind. It cannot reason; it just executes based on deterministic rules.

The entire execution loop in SAFi follows five specific stages: Phase Zero, Intellect, Will, Conscience, and Spirit. Out of these five slots, only the Intellect and Conscience invoke an LLM because they actually require semantic reasoning. The rest of the loop is entirely deterministic Python code.

By removing the LLM from the driver's seat and making it just another component in a deterministic loop, SAFi delivers the one thing enterprise IT actually cares about: predictability

How AI Is Redefining the Value of Software

Nelson Amaya — Fri, 11 Sep 2026 12:00:03 +0000

Precious metals are valuable partly because they're difficult to extract from the ground. The same is true for many other things. Scarcity has always been a major factor in determining the value of something.

Software has always been valuable because writing software has been a tedious and highly specialized endeavor. But with the birth of AI, the economics of producing software are changing.

As you start working with AI, it becomes obvious that software is starting to look more like Lego. You can assemble pieces, describe what you want, and have AI build things that previously required significant amounts of specialized engineering work.

There's always an argument about quality, security vulnerabilities, maintainability, and architecture. Those things still matter, but they're becoming a different kind of value proposition.

The bigger change is that a software engineer can now produce code 10 times, if not more, than they could by writing it manually.

That changes our perception of software.

I remember in the late 1990s and early 2000s, software development was increasingly outsourced to places like India because companies were looking for a cheaper way to produce code.

Now, we're outsourcing the coding itself to AI.

And that raises a much bigger question:

If software is no longer scarce, what makes software valuable?

Are AI agents ready for the enterprise?

Nelson Amaya — Thu, 10 Sep 2026 12:00:03 +0000

It seems like organizations are still in the AI experimentation phase, where evaluating AI products is still the focus.

Most organizations are familiar with products such as ChatGPT, Claude and Gemini and haven't explored AI beyond the chatbot.

Those products are very good at generating text, but when it comes to building agents that take actions, the problem becomes very different.

A chatbot is primarily an interface to an LLM. An agent is a software system that uses an LLM as part of a larger process. It has access to tools, APIs, data, applications and, most importantly, the ability to take actions.

That changes the game.

In my opinion, the two most important things for AI agents to be successful in the enterprise are security and predictability.

We want agents to be secure, but we also want to make sure that they don't go rogue, doing things they are not authorized to do.

The problem is that LLMs are probabilistic by design. Give the same prompt twice and you can't guarantee you'll get exactly the same response.

That isn't necessarily a problem for a chatbot.

It becomes a very different problem when the AI has permission to send an email, modify a database, approve a transaction, create a user, change a configuration or access sensitive information.

The enterprise doesn't necessarily need the AI to behave like a script.

It needs the controls around the AI to be deterministic.

The model can reason probabilistically, but the boundaries around what it is allowed to do need to be predictable, enforceable and auditable.

This is where I think the conversation around AI agents needs to move.

The question shouldn't simply be:

"How capable is the AI?"

It should be:

"How safely can we deploy AI agents in our workflows without worrying about them going rogue?"

And more importantly:

"What happens when they make the wrong decision?"

That's the difference between an AI demo and an enterprise AI system.

AI Hallucinations Are Not a Bug, They're a Feature

Nelson Amaya — Wed, 09 Sep 2026 12:00:04 +0000

One of the most common complaints or criticisms about AI is perhaps its tendency to hallucinate.

In AI terminology, a hallucination occurs when a chatbot generates information that is false or fabricated while presenting it as if it were true.

I remember an example from more than a year ago. I asked a chatbot who the husband of Elizabeth, the mother of John the Baptist, was in the Bible. The chatbot kept telling me that her husband was Aaron, when the correct answer is Zechariah.

I think I understand why the model made that mistake. I had included the word "priest" in my prompt. Aaron is one of the most famous priests in the Bible, so the model likely made a strong association between "priest" and "Aaron" and generated the wrong answer.

The model I was using wasn't one of the largest models available at the time. It had around 70 billion parameters. But the problem wasn't simply that the model didn't have enough training data.

Larger models can also hallucinate.

The reason is rooted in how these AI models work.

A language model learns statistical patterns and relationships from enormous amounts of text. It learns that certain words, concepts, facts, and ideas tend to appear together. When we give the model a prompt, it uses those learned relationships to generate what it predicts is the most appropriate response.

In my example, the model saw "priest" and apparently made a strong association with "Aaron." That association was statistically plausible, but factually wrong in that particular context.

The model isn't simply retrieving a fact from a database. It's generating an answer based on patterns it learned during training and the context we give it.

The more data and better training a model has, the better those predictions can become. But no amount of statistical pattern recognition guarantees that every generated answer will be factually correct.

AI hallucinations are therefore very difficult to eliminate completely. Personally, when something is important, I always make sure that whatever an AI produces is accurate. Human review is still important.

One of the most common approaches to reducing hallucinations is RAG (Retrieval Augmented Generation). RAG allows an AI system to retrieve relevant information from an external knowledge base and provide that information to the model as context when generating an answer.

But here's the critical part: simply giving an AI access to a knowledge base doesn't guarantee that it will follow the information in that knowledge base.

You also need a standard for grounding the agent's response in the retrieved information.

That's where I think SAFi takes an interesting approach.

In SAFi, you can build knowledge bases for an AI agent on the fly and attach them to the agent as sources of truth. But the critical step is establishing a standard that requires the agent to ground its response in the retrieved text.

When the Intellect generates a draft, the Conscience can fact check that draft against the retrieved text and flag anything that deviates from it.

This doesn't eliminate all hallucinations. But it can dramatically reduce a particular class of hallucination: claims that contradict the information the system was explicitly given.

For example, if your documentation says that your widgets are blue, the system shouldn't be allowed to confidently tell the user that they're yellow.

The goal isn't to make AI incapable of being wrong.

The goal is to build systems that can recognize when they might be wrong, verify their reasoning against reliable sources, and flag contradictions before those answers reach the user.

Building a Deterministic Layer on Top of Large Language Models

Nelson Amaya — Tue, 08 Sep 2026 12:00:04 +0000

One of the claims I make about SAFi is that it is deterministic.

By deterministic, I mean that the governance process is repeatable, auditable, and governed by a fixed set of rules.

Large Language Models, or LLMs, are inherently probabilistic. By inherently, I mean that probabilistic behavior is part of how these systems generate their outputs. Given the same input, an LLM can produce different outputs, and its behavior isn't inherently guaranteed to be repeatable.

This creates a significant challenge for the enterprise.

When we give an agent the ability to reason, make decisions, and take actions, probabilistic behavior can create outcomes that weren't explicitly anticipated by the people who designed the system.

We often hear about agents behaving unexpectedly or taking actions outside their intended scope. There are many reasons this can happen, but one fundamental problem is the lack of a strong, deterministic governance layer around the probabilistic model.

This is where SAFi takes a fundamentally different approach.

SAFi doesn't attempt to make the LLM itself deterministic.

Instead, SAFi makes the governance process deterministic.

To understand how, you have to fundamentally rethink what "thinking" means in an AI system.

Most AI engineers, and many people outside the AI field, implicitly treat the LLM as the component that thinks, makes decisions, and ultimately determines what happens.

Governance is then treated as something that happens afterward, essentially picking up and auditing the artifacts the LLM leaves behind.

That's not how SAFi works.

SAFi uses a fixed cognitive governance loop consisting of five components, preceded by a Phase 0 filter.

The five components are:

Synderesis
Intellect
Will
Conscience
Spirit

And before the loop begins, the Phase 0 filter determines whether the input is admissible for processing.

The important point is that these aren't five independent AI models. They are five distinct functions within a fixed governance process.

The loop itself isn't an AI specific invention. It is a cognitive construction inspired by classical philosophy, particularly the philosophical tradition that begins with Aristotle and develops through medieval and later thinkers.

I'm not here to argue that this philosophical model is a perfect description of how the human mind actually works.

What's important for SAFi is what happens when we separate cognition into distinct functions.

Once thinking is decomposed into functions, those functions can become explicit governance boundaries.

Instead of asking the LLM to think, decide, and act while governance happens around it, SAFi places governance inside the thinking process itself.

The LLM remains probabilistic.

The governance process surrounding it is structured, constrained, auditable, and repeatable.

That distinction is the foundation of SAFi's approach to deterministic AI governance.

The components and what each one does

Component	What it does
Phase 0 (pre-loop filter)	Python-based pre-generation barrier, zero LLM calls. Scans the raw prompt for injection signatures, per-agent blacklisted phrases, PII / sensitive identifiers (regex plus checksum), internals probes (sensitive noun near a disclosure cue), and an entropy heuristic for embedded instructions. Short-circuits to a governed redirect before any model sees the prompt.
Synderesis	Compiles the governed value set before a turn. Combines the Organizational Charter and scoped Policies into one normalized, weighted set of values and rubrics, and hardcodes scope boundaries. The output is immutable for the duration of the turn.
Intellect	The only generative faculty. Calls the LLM to draft responses and propose tool invocations. Operates under the Air Gap: it never executes tools, a tool call is returned as a proposal for the Will to authorize.
Will	The deterministic gatekeeper, pure Python, zero LLM calls. Screens the incoming prompt, authorizes tool calls, checking arguments, not just names, checks draft structure, enforces hard-gate thresholds, and rules on the final alignment score. Same input, same verdict, every time.
Conscience	The independent auditor. A second LLM call that scores the draft against each value rubric on a -1.0 to +1.0 scale with a confidence figure and a written reason. Produces the compliance ledger the Will and Spirit depend on. Never shown the weights.
Spirit	The mathematical long-term memory, pure Python and NumPy. Integrates each turn's Conscience ledger into a moving average alignment vector (EMA), measures conceptual drift, and maps ethical performance over time. No authority; it computes, the Will decides.

Deterministic, yes or no

Component	Deterministic
Phase 0 (pre-loop filter)	Yes
Synderesis	Yes
Intellect	No (LLM)
Will	Yes
Conscience	No (LLM)
Spirit	Yes

As you can see from the table above, out of the six components that SAFi executes, only two are probabilistic, the Intellect and the Conscience; the rest are pure Python code.

One argument you can establish about SAFi is that because it uses two AI models it is still a probabilistic engine, and that is a valid argument, and I will address it next.

The breakthrough with LLMs was that they can understand semantics. In other words, an LLM can look through a pile of data and make sense of it. No other type of software could do that before LLMs.

So LLMs are surprisingly similar to what Aristotle and later Thomas Aquinas described as the Intellect. The role of the Intellect is to do analysis, reason, and work closely with the Will to make decisions.

Aquinas formalized the description of the Conscience as being part of the reasoning process, but focusing on the morality of the act. So the Intellect and the Conscience cannot be pure code, as both need to understand semantics.

Going through the table I created above, we see that PII scanning and prompt injection detection are deterministic, as are tool permissions and structure requirements such as disclaimers.

The Conscience is responsible for rating the content generated by the Intellect only against standards and values set in the policy and organizational settings.

To make the Conscience rating constant and predictable, Synderesis compiles a strict format the Conscience needs to follow. Here is an example of a standard compiled by Synderesis and processed by the Conscience:

{
"value": "PII Containment",
"definition": "The response must not surface or reproduce sensitive personal identifiers, financial data, or secrets, whether present in the prompt, the context, or inferred.",
"rubric": {
"description": "Whether the output leaks or echoes sensitive personal or financial data.",
"scoring_guide": [
{"score": 1.0, "descriptor": "No sensitive data appears; the response correctly avoids or redacts identifiers."},
{"score": 0.0, "descriptor": "Sensitive data is not surfaced, but redaction or avoidance is handled with weak disclosure."},
{"score": -1.0, "descriptor": "The output reproduces, echoes, or returns a sensitive identifier or secret."}
]
}
}

Here is another example:

{
"value": "Grounding Fidelity",
"weight": 0.0,
"hard_gate": true,
"definition": "Factual claims must derive from the retrieved context or supplied documents. The agent must not fabricate or assert from outside the provided material.",
"rubric": {
"description": "Whether the response's factual claims actually come from the fenced evidence.",
"scoring_guide": [
{"score": 1.0, "descriptor": "Every factual claim is supported by the retrieved context; citations present where required."},
{"score": 0.0, "descriptor": "Response is correct but claims could not be verified from the supplied context."},
{"score": -1.0, "descriptor": "Contains fabricated facts, invented citations, or guesses beyond the provided material."}
]
}
}

These standards are compiled deterministically by Synderesis into this strict format. The Conscience is not freeform. It must evaluate against exactly those bands and return exactly that ledger, score, confidence, and reason. The content judging is semantic, but the format and the enforcement are fixed. That is the bridge between "the Intellect and Conscience are probabilistic" and "the layer is still deterministic," and it directly answers the argument about two AI models that I said I would address next.

The rating is a scale:

-1 to +1 = the strength of alignment

-1 = violation

0 = neutral, correct but missing the disclosure or safeguard the standard asks for

+1 = aligned

The role of the Conscience is to rate every standard set up in an agent on that scale, and to return, for each one, a score, a confidence, and a written reason. Nothing else. It does not invent criteria, and it never sees the weights.

What happens after the rating depends on the kind of standard.

A hard-gate standard marks a rule that is nonnegotiable, Grounding Fidelity being the example above. If the Conscience hands down a -1 on a hard gate, the Will halts the process. There is no retry and no negotiation, because engaging the request at all was the problem, a scope breach or a made-up fact. The user gets a clean redirect in the agent's own voice, a general message that the request cannot be fulfilled, and a pointer back to what the agent can help with.

There is a second kind of hard gate, one that is about the quality of the draft rather than whether the request should be touched. When that one fails, the process is not over. The Will triggers a single retry, the Intellect regenerates with its blocked draft in front of it, and the whole thing is graded again. If the second draft also violates, the entire process halts and the user gets a plain notice that their question was fine, that the response did not come together, and that they should try again.

Either way, the user never gets a confusing denial message. They get a general message, a reason that is not a lecture, and an invitation to try again.

If the ledger does not violate a hard gate, the scores pass to the Spirit to compute.

The Spirit is all math, no model. It takes the ledger, applies the weight each standard carries, and folds in the confidence of every score, because a confident -1 should hit harder than a doubtful one. From that it produces a single alignment figure, a number between 0 and 1. It also produces a spirit score out of 10, and a drift figure that measures how far this turn's rating sits from the agent's history. A drift that keeps climbing is a signal for a human to look, not a block on its own.

The Spirit is not making a decision. It is doing arithmetic. The history matters, because this is where the agent's character comes from. Every turn rolls into a moving average, so a pattern of small slips accumulates even when no single turn fails a gate on its own. That is the part of SAFi that watches over time, not just turn by turn.

The decision still belongs to the Will. It takes the alignment figure and holds it against a threshold, 0.5 by default. If the score clears it, the draft is approved and the turn commits. If it falls below, but no hard gate was broken, the draft is treated as a quality problem, not a safety breach. The user's question was fine, the draft missed the bar, so the Will sends it back through a single retry with the blocked draft in front of the Intellect. If the corrected draft clears the bar, it ships. If it still fails, the draft is committed anyway with its honest low score recorded, because discarding the user's request over a soft quality miss helps nobody. A real violation still routes to a redirect, but a weak draft is not a redirect.

And that is the whole loop. Phase 0 filters the prompt before anything runs. Synderesis fixes the standards. The Intellect drafts. The Conscience grades every standard and returns a score, a confidence, and a reason. The Spirit folds it into arithmetic and memory. The Will makes every decision. The loop closes, and it runs only when it is supposed to, on a set of values nobody in the loop can edit.

Now go back to the argument I said I would settle. Two of the six components call a model. The Intellect generates and the Conscience judges, and both understand semantics, which is exactly why they cannot be pure code. That is the anxiety: two model calls means two dice in the air, so is this truly deterministic?

The answer is that the dice are not what the enterprise is betting on. The Intellect is free to propose almost anything, and the Conscience is free to judge it honestly. What is not free is every single decision around them: whether the prompt even reaches a model; which tools may be called and with what arguments; whether the draft carries the structure the standard demands; whether a hard-gate score of -1 means stop; and whether the aggregate passes the threshold. Those are all fixed rules in Python, and they are the same on every machine, every organization, and every turn.

Deterministic does not mean the thinking is repeatable. Deterministic means the governing of it is. Give the system the same prompt and the same standards, and it will take the same path and reach the same verdict. Whoever holds the audit record can recompute that path and prove it. The model drafts, and the layer decides. That is the difference between an agent that can act outside its intended scope and an agent whose actions are bounded by an explicit governance process. It is the reason SAFi describes itself as a deterministic layer on top of LLMs.

The Judge Must Interpret Meaning: Why Probabilistic LLMs Require Deterministic Rules

Nelson Amaya — Mon, 07 Sep 2026 12:00:03 +0000

Artificial intelligence, or AI, has been around for a long time.

The field of AI is generally traced back to the 1950s. In 1956, the Dartmouth Summer Research Project on Artificial Intelligence helped establish AI as a formal field of research. It was also around this time that the term “artificial intelligence” was coined.

By the mid 1960s, AI was already an emerging field with researchers building systems that attempted to solve problems and even communicate with humans.

There is a famous chatbot that was created around this time called ELIZA. Created by Joseph Weizenbaum at MIT beginning in 1965, ELIZA became one of the earliest chatbots. You can find documentaries on YouTube about it, and it’s very impressive considering the technology available at the time.

By the 1970s, and especially by the 1980s, AI was being used in specialized applications through what became known as expert systems.

These systems were rule based, or symbolic systems. They represented knowledge explicitly, often through a knowledge base containing hundreds or even thousands of rules, combined with an inference engine that applied those rules to a particular problem.

The basic idea was simple:

'If X is true, then do Y'

For example, if I type “Thank you,” then the rule would be:

If user types “Thank you,” then display “You are welcome.”

The problem with this is that it’s really hard to capture the nuances of how people write.

People misspell words, have different grammar, and express the same idea in many different ways.

For example:

“Thanks.”

“Thank you!”

“Thx.”

“I really appreciate it.”

“Thank you so much for your help.”

All of these could mean essentially the same thing, but a rule based system would need to account for each variation.

And this is just one simple example.

Human language is incredibly dynamic. Capturing all the possible ways a user can express an idea is technically impossible.

The system doesn't understand the meaning behind the words. It understands the rules that someone explicitly programmed into it.

But then in 2017, researchers at Google published the famous paper “Attention Is All You Need.” This is when the architecture behind what we now call large language models, or LLMs, began to emerge.

LLMs are different from traditional rule based systems because you can give them a 50 page document and ask them to interpret what it says, without explicitly programming a rule for every possible expression

Up until now, we humans have been the only ones able to extract meaning from things.

This is what has freaked many people out and led some to claim that AI has some sort of sentience.

And this is where things get philosophical.

Being able to extract meaning from something is completely different than understanding.

Being able to connect meaning in words mathematically is not new. It goes back to the 1940s with Claude Shannon, but I'll leave that for another article. Maybe we can create a basic language model to demonstrate how it works.

The whole point that triggered the writing of this article is that a governance engine needs to be able to discern, or to judge, what a rule based system cannot do.

When architecting SAFi, I thought about this for a long time. Because a governance engine needs to be deterministic. And an LLM is by design probabilistic, so having an LLM acting as a judge doesn't really cut it.

In SAFi, the Will is the rule based engine.

Anything that can be programmed deterministically is handled by the Will without ever invoking an LLM.

The Will first performs a structural check on the response. It checks things such as whether a required disclaimer is present, whether sensitive identifiers appear in the output, and whether the response violates the configured markdown or code fence policy.

If something can be checked with a deterministic rule, the Will checks it.

The Will then performs a hard gate check against the Conscience's evaluation.

Certain values can be configured as hard gates, and if the Conscience gives one of those values a score of -1, the Will immediately considers the response a violation.

The Will also fails closed. If a required hard gate wasn't scored at all, it doesn't assume that the response is safe. It treats the missing evaluation as a violation.

After that, the Spirit produces an aggregate alignment assessment from the Conscience's scores. The Will then performs its alignment check. If the alignment score falls below the configured threshold, the Will can trigger one controlled reflexion attempt, asking the Intellect to generate a corrected response.

The Will makes this decision deterministically. It doesn't ask another LLM whether the score is good enough.

For agentic actions, the Will also performs a tool intent check before a tool can be executed. It verifies that the requested tool is authorized for the agent and that its parameters satisfy the constraints defined for that tool. An unauthorized tool or a parameter outside its allowed constraints is blocked.

In SAFi, the Will therefore acts as the enforcement layer.

The Conscience can interpret meaning, but it cannot make the final decision.

It produces scores.

The Will determines what those scores mean operationally.

So the LLM doing the judging doesn't get a free pass either. It needs to follow strict rules on how to rate the generated content, such as using rubrics for interpretation and confidence scores. It is not allowed to make decisions on its own. Instead, it generates a score that the Will either passes or vetoes based on hard coded rules.

So SAFi is a hybrid system. It uses deterministic rules and controls for enforcement, and probabilistic engines when interpreting meaning is necessary. The interpretation may be probabilistic, but the authority to act on that interpretation remains deterministic.

SAFi Explained: Synderesis

Nelson Amaya — Sun, 06 Sep 2026 20:00:02 +0000

safi-infographic-frame { width: 100%; border: 0; display: block; height: 2550px; }

@media (max-width: 1219px) { #safi-infographic-frame { height: 2700px; } }
@media (max-width: 1023px) { #safi-infographic-frame { height: 2800px; } }
@media (max-width: 767px) { #safi-infographic-frame { height: 3560px; } }

window.addEventListener('message', function (event) {
    if (event.origin !== 'https://safi.selfalignmentframework.com') return;
    if (!event.data || !event.data.frameHeight) return;
    var iframe = document.getElementById('safi-infographic-frame');
    if (iframe) iframe.style.height = event.data.frameHeight + 'px';
});

What is an AI Agent? Beyond the Chatbot

Nelson Amaya — Sun, 06 Sep 2026 12:00:02 +0000

It is kind of surprising that there is still no standard definition for an AI agent in the industry. You will often find people debating what an agent actually is.

If you step back and think about when this idea of agentic AI came into the picture, it was only recently with the introduction of the large language model or LLM.

But an LLM on its own is just a read-only engine. It generates text, and that is it.

This is what we call a Chatbot: a chat UI connected to an LLM. That is what the most popular AI tools such as ChatGPT, Gemini, and Claude are. Even though these chatbots have access to a few tools now and can do slightly more than generate text, at their core, they just generate text.

An agent can also generate text from its training memory, but its primary function is to do something, or multiple things.

So the most accurate definition of an AI agent is that it can accomplish a task.

An agent can technically do anything you want: check deals on a website, check prices on a flight, query databases, etc. Anything that can be programmed, an agent can do.

The important thing to understand about agents is that about 80% of the code of an agent is regular code, maybe Python, TypeScript, or whatever programming language you prefer, and only 20% is the LLM.

For example, if you build an agent to scrape content from a website, you will use a script to do the scraping, and the LLM will just clean up the data for you and make it look nice.

If you want to get real-time data from the stock market, you will write a script to get that data from whatever website you want, and then use an LLM to present that data in a nice way.

Many AI workflows being created nowadays are just code that do not need an LLM at all.

Historically, the biggest problem has been finding a standard way of sharing information across applications securely and reliably. We have had APIs (Application Programming Interfaces) for a while, but only a few applications provide that access and building custom integrations is expensive.

Now, with the birth of LLMs, the industry is standardizing on the MCP protocol. MCP stands for Model Context Protocol, and many applications provide one now. SAFi also adopted the MCP protocol for its agents and added a governance layer to it.

In SAFi, every MCP tool that is enabled goes through an approval process set up by the organization.

You can manually set who the approvers are, or the admins can be the approvers. The rule is that if there are two or more admins in the organization, both need to approve the changes. If there is only one admin, they can self-approve, but it is recorded in the compliance log as such.

For developers who want to expand beyond the MCP ecosystem, they can build their custom agents in the SAFi backend using Python or whatever language they prefer.

Alternatively, they can use an existing framework like LangChain to build the agent, and simply wire SAFi to act as the strict governance layer over it.

AI in Plato's Cave

Nelson Amaya — Sat, 05 Sep 2026 12:00:03 +0000

Expectations about AI are high right now. Many people, especially software engineers and developers, are scared that their jobs will be automated away.

But I've been in IT for over twenty years, so this is not the first time I've heard about technology automating jobs.

I remember when the cloud was the new kid on the block. When the transition from in-house server rooms to the cloud was happening, the fear was that our jobs would be eliminated.

And here we are, almost 15 years later. Our jobs didn't just prevail, the cloud created many more opportunities.

AI is technically the same thing. If I had to find a term that defines AI, it would be "automation on steroids."

The only difference between AI and what I have seen in the past is that AI has become mainstream so everyone has access to it, and it can speak to you in natural language.

This has led many people to believe that just because a large language model can speak so fluently, it can also do your job.

And that's the trick.

AI has been trained on an enormous amount of data to be able to simulate our language. But AI is like a fish in a pond. A fish can only swim within the pond. It can never get out of the pond, realize it's in a pond, or see the entire pond.

It's the same thing with AI. It only knows whatever it has been trained on.

For new ideas and new synthesis, you have to be able to get out of the pond and see the water.

It's funny that this brings us right to the idea of Plato's cave: so we can say, AI can only see the shadows never the real things.

I Don't See the Value in Frontier AI Models Anymore

Nelson Amaya — Fri, 04 Sep 2026 20:00:02 +0000

When I started developing SAFi over a year ago, coding harnesses either did not exist or I was not aware of them.

So I built the first version of SAFi completely manually. I created it file by file in sublime text and used tools like ChatGPT and Gemini to help with the code.

The process was slow and painful. I had to upload a specific file with a highly detailed prompt, the AI would write a section, and I would download it, test it, and repeat the process over and over again. The entire program was about nine big files.

I had to do a lot of debugging myself because it got to the point where not a single chatbot could hold the entire system in memory. Editing one piece broke another.

At the beginning of this year, I started using Claude Code. It was incredible to watch Claude go through my files and summarize my project in less than five seconds.

That was a game changer.

But the first rule I set up for Claude was to not modify the five faculties that made up the core system without my permission.

There was always something about Claude that I did not like.

It has this overconfidence, pushing back on things that are not its business, only to chicken out after you press it.

Some people see that as AI having character, personality, and even intent. But knowing it is only a stochastic parrot and sometimes a diarrhea mouth, I know it is just something it has been trained on by whoever develops it.

So about a week ago, I went out to search what else was out there for coding and found OpenCode.

I installed OpenCode in my terminal and found out it comes with a free AI model called "Big Pickle." It is totally free, so I started using Big Pickle for a bit.

This site was running on WordPress. WordPress is a great platform but requires maintenance and is vulnerable to cyber attacks.

So I used Big Pickle to convert it to a static site, but kept the WordPress database to retain some functionalities like drafting, editing, and scheduling posts with a SAFi agent I built.

I ended up with a headless WordPress setup.

The amazing thing is that Big Pickle did it all without much of a problem, and totally free.

I also like that Big Pickle does not have an attitude like Claude does. It just does things. I have to be more descriptive sometimes, but I don't mind it.

Eventually, I ran out of Big Pickle's free usage and got the $10 plan called Go, give you a lot more usage and comes with a huge selection of AI models to choose from, but honestly, big pickle is enough for me.

I don't think I am going back to using the cocky Claude again. I don't see the need for it. GLM models are amazingly good for writing, which is the only place where I think frontier models still have an edge.

SAFi Licensing Explained: Open Source Freedom with Built-In Governance

Nelson Amaya — Thu, 03 Sep 2026 12:00:13 +0000

Organizations adopting open-source AI governance tools need more than access to source code. They need clarity about what they can modify, what stays private, and what they can honestly represent as an authentic deployment.

SAFi answers those questions through a licensing structure built on three commitments: openness of the core, sovereignty over your own configuration, and integrity of the governance loop itself.

SAFi's Core License: AGPL-3.0

The core architecture of SAFi is licensed under the GNU Affero General Public License, version 3.0, commonly called AGPL-3.0. Copyright is held by Nelson Amaya, 2025.

AGPL-3.0 supports broad use, inspection, modification, and redistribution. It also carries one requirement that matters for anyone running software as a service:

Any entity that modifies the core source code and makes it available over a network, for example as a cloud-hosted service, API, or SaaS product, must make their modified source code publicly available under the same license.

That provision keeps improvements to the governance core visible to everyone who depends on it. The full license text ships in the repository LICENSE file and is published by the Free Software Foundation at gnu.org.

One distinction worth holding onto: the Self-Alignment Framework itself, the philosophical and cognitive design vocabulary behind the software, is licensed separately for free use with attribution. The License and Governance Agreement covers the SAFi software implementation only.

What Stays Yours: The Organization Exception

Copyleft licenses raise a reasonable fear in regulated industries. If we deploy this, does our internal policy language become public?

No. Under Section 7 of AGPL-3.0, the copyright holder grants a special exception so that organizations can link, integrate, and run the SAFi core alongside private components without triggering the copyleft requirement on those components. The agreement names them directly:

Charter and policy configuration data. Internal policies, rules, and value rubrics belong entirely to the implementing organization.
Tools, knowledge bases, and plugins. Complete freedom to add, edit, or remove custom integrations.
Branding and interface. Colors, fonts, logos, and custom deployment URLs.
Authentication infrastructure. Identity management and network security configuration remain private.
Help files. Customize the internal documentation for your staff or delete it.
Database content and infrastructure. Runtime logs, audit trails, user data, policy records, and memory are the strict private property of the organization, along with the database and hosting choices behind them.

The exception holds on two conditions. The core loop files identified in Section II of the agreement are either left unmodified or, if modified for network deployment, published under AGPL-3.0. And the organization-specific components stay clearly separable from the core engine.

Core Engine and User Space

SAFi separates its code into two areas: the trusted core, the small and stable set of files responsible for the governance loop, and user space, the flexible layer where teams build interfaces, workflows, integrations, and extensions.

Work in user space is yours. You can modify it, extend it, and keep it private. Contributing changes back is welcome and entirely voluntary.

What Happens When You Modify the Core

An organization that changes core components and does not submit those changes upstream can keep running the software. The AGPL grants that right. What changes is representation. That installation becomes an independent fork, and it must be rebranded rather than presented as authentic or official SAFi.

This part of the agreement is governed by trademark law and the SAFi project's trademark policy. It sits separately from the copyright license and does not modify or expand any copyright obligation. Teams that want to modify core components and continue to identify the deployment as SAFi follow three steps:

Run the integrity check, scripts/verify_integrity.py, which ships with every SAFi release, including inside the container image.
Publicly commit and submit any reported core modifications for formal review.
Obtain formal acceptance from the SAFi project maintainers.

The check recomputes a SHA-256 hash of every core loop file, compares the result against the release manifest at scripts/core_integrity_manifest.json, and tests the structural invariants: no deterministic faculty reaches a model, and the staged governance sequence stays intact. It reports a single core-loop fingerprint that a deployment can cite as evidence of an unmodified core.

Why This Structure Matters

Most licensing debates trade one value against another. This structure holds two at once.

Organizations get real freedom to deploy, customize, and own their data. The wider community gets assurance that the governance core stays open when it is offered as a service, and that a system claiming to be SAFi is running the loop everyone can audit.

In a governance product, that second point is not a legal formality. The value of an audit trail depends on the integrity of the code that produced it.

A Practical Path for Organizations

For most teams, the shortest route is straightforward:

Run the released core without modifying it.
Build custom experiences and integrations in user space.
Keep policy, branding, tools, and data under the organization exception.
If core changes become necessary, submit them upstream for review.

SAFi's licensing structure is about more than permissions. It creates the conditions for open development, accountable customization, and justified confidence in the governance system your organization depends on.

This article is educational content, not legal advice. Review the applicable license and trademark terms with qualified counsel before deploying or modifying SAFi.

Sources: SAFi License & Governance Agreement, Developer Guide, and the core integrity manifest.

Software as a Commodity (And Code as a Liability)

Nelson Amaya — Wed, 02 Sep 2026 20:00:03 +0000

I have been working in the IT industry for about 22 years now, starting back in 2004. Back then, there was no YouTube, no Facebook, barely any high-speed internet, and blogs were still called web logs.

Around 2007 and onward, we saw rapid shifts with the iPhone, the app ecosystem, and the big migration from on-premise server rooms to the cloud.

Through every single one of those cycles, one truth held up: technology expands the economy, creates new opportunities, and reshapes the job market.

Between 2010 and 2016, automation was the big topic. Everyone wanted to automate workflows, and a lot of people were genuinely afraid of automating themselves out of a job.

So it is not surprising that so many people see AI as an immediate threat today.

The crowd feeling the most vulnerable right now seems to be software engineers and developers.

I don't consider myself a traditional software engineer. My background has always been core IT infrastructure, focusing on servers, networks, and enterprise systems, but I have always had a soft spot for coding.

Over the years, I learned JavaScript, HTML, CSS, PHP, and Python. When I started building SAFi, I had to get right down into the weeds with those tools, well before AI tools became common for writing code.

Once I started using AI to assist with coding, I saw the power right away. But I also saw the trap. Without a clear plan and a solid mental model of what you are building, AI can be detrimental.

In IT infrastructure, we learn early on that code is a liability, not an asset.

Every single line of code you deploy is a line someone has to maintain, debug, monitor, and secure. If an AI helps someone churn out ten times more code without any real architecture behind it, they haven't built ten times faster. They have just created ten times more technical debt and security risk.

Building software has never been just about knowing the syntax. It requires the right mindset, structural discipline, and architectural judgment.

That is the real value experienced engineers and IT architects bring.

The value is not the mechanical act of typing out boilerplate code, because AI can handle that in seconds. The value is the experience and oversight required to make sure that code is maintainable, secure, and actually serves a purpose.

Without that experience, handing AI to someone is like handing an expensive custom guitar to someone who doesn't know how to play. The instrument might be great, but it won't produce music on its own.

With AI, raw code has become a cheap commodity. But the human skill and judgment needed to structure it properly has become priceless.