DEV Community: Nelson Amaya

Not Every AI Task Requires a Frontier Model

Nelson Amaya — Sat, 22 Aug 2026 20:00:35 +0000

The AI industry often treats the most powerful model as the default answer to every problem. That approach is convenient, but it is rarely efficient.

Many AI workflows contain a mixture of simple, repetitive, exploratory, and high-stakes tasks. Asking a frontier model to handle all of them can increase cost, latency, and token usage without producing better results.

SAFi takes a different approach. Through its model-independence principle, SAFi lets organizations choose the model that best fits each task, regardless of provider.

Match the model to the work

A useful AI workflow does not need to rely on one model for every step. It can assign different models to different stages based on complexity, speed, cost, and quality requirements.

For example:

Background tasks can use fast, economical models.
Brainstorming can use models optimized for quick idea generation.
Early drafts can be produced with lower-cost models.
Review and refinement can use a more capable model when needed.
Final drafts can be reserved for a frontier model when quality and nuance matter most.

This creates a practical model-routing strategy. The strongest model is available for the work that benefits from it, but it is not needlessly used for every intermediate step.

The result is a more balanced workflow: lower operating costs, faster responses, and better control over where premium model capacity is spent.

Model independence prevents provider lock-in

SAFi is designed to work across models and providers rather than tying governance to a single vendor.

That flexibility matters because the AI model landscape changes quickly. New models may offer better performance, lower prices, improved privacy, or stronger capabilities for specific tasks. A governance platform should not force an organization to rebuild its controls every time its model strategy changes.

With model independence, teams can evaluate models according to their own requirements and select the right option for each workload. They can also change providers without changing the underlying governance approach.

The policies, decisions, and oversight remain consistent even when the model changes.

More context is not always better

Model selection is only one part of controlling AI costs. Conversational memory also has a direct impact on token traffic, latency, and efficiency.

It is tempting to send an entire conversation history with every request. Sometimes that is necessary. Often it is not.

A short background task may only need the latest instructions. A brainstorming session may benefit from recent context but not every message from the beginning. A drafting task may need the current outline and selected notes, rather than the full history of every revision.

SAFi gives users control over how much conversational memory is passed to the model.

By default, SAFi provides two full runs and then summarizes the conversation. This approach preserves continuity while limiting the amount of repeated context sent to subsequent model calls.

For tasks that genuinely require complete conversational history, memory can be set to unlimited. The important point is that full history is an option, not an unavoidable overhead.

Efficient context management keeps token traffic low

Token usage grows when large histories are repeatedly included in model requests. That can affect both cost and performance, particularly in workflows with many sequential calls.

SAFi’s memory controls support a more deliberate approach:

Use full conversational context when continuity is important.
Allow the system to summarize after the default two full runs.
Retain only the information needed for the next stage.
Enable unlimited memory for tasks where historical detail is essential.

This gives teams a way to balance context quality with operational efficiency.

The goal is not to minimize context at all costs. The goal is to provide the right context for the task.

A practical workflow for organizations

Consider an organization preparing a policy document.

A lower-cost model might first collect ideas, organize notes, and produce an initial structure. Another model could identify missing sections or compare the draft with internal requirements. A more capable model could then refine the language, resolve ambiguities, and prepare the final version for human review.

The organization does not need to use its most expensive model for collecting notes or generating rough alternatives. It can reserve that model for the parts of the workflow where judgment, precision, and communication quality matter most.

Throughout the process, SAFi provides the governance layer. Policies can govern agent actions, and decisions can be recorded for review and audit. The model may change from one step to another, but the organization’s controls remain in place.

Efficiency is part of responsible AI operations

Model choice and memory management are not merely cost-optimization features. They are part of responsible AI operations.

Using an unnecessarily large model for routine work can waste resources. Sending unnecessary history can increase exposure to irrelevant or sensitive information. Choosing the right model and the right amount of context supports a more controlled and transparent system.

This is especially important as organizations move from isolated experiments to production AI workflows. At scale, small inefficiencies multiply across thousands of tasks and model calls.

A well-governed system should therefore ask two questions:

What level of model capability does this task actually require?
How much conversational context does the model actually need?

SAFi helps make those decisions configurable rather than accidental.

Build workflows around outcomes, not model prestige

The most capable model is not automatically the best model for every job. A strong AI architecture separates the work into stages and assigns resources according to the outcome required at each stage.

SAFi supports that architecture by combining:

Model independence across providers
Flexible model selection for different tasks
Configurable conversational memory
Lower token traffic through summarization
Governance of agent actions
Recorded decisions for auditability

This approach gives organizations more control over cost, performance, privacy, and operational consistency.

Frontier models still have an important role. They can be valuable for complex reasoning, sensitive communication, and final drafts. But they should be used where their additional capability creates meaningful value.

Not every AI task requires a frontier model. With SAFi, organizations can use the right model, with the right amount of context, under the right governance controls.

That is a more practical way to scale AI.

Why SAFi Is Going All In on Progressive Web Apps

Nelson Amaya — Thu, 20 Aug 2026 12:00:03 +0000

Since the first day I started building SAFi, two questions have sat side by side on my mind: how do we make this available on every device, and how do we do it without weakening the security posture the architecture is built on?

Those two goals usually pull against each other. The common answer is to ship native apps for iOS and Android, a desktop client, and a web app. That means multiple codebases, multiple release cycles, and multiple attack surfaces to monitor.

Every additional codebase is another place where a dependency goes stale, a permission gets misconfigured, or a patch lands late. For a governance platform, where the whole promise is that declared values and real behavior stay aligned, that kind of drift is not acceptable.

So SAFi is adopting a Progressive Web App architecture for both mobile and desktop access.

One codebase. The JavaScript, HTML, and CSS in the public directory serve every surface, from a phone on a trailhead to a workstation in a compliance office.

When we ship a fix, every user has it on next load. There is no waiting on app store review, no fragmented version sprawl, and no separate mobile build quietly running last quarter’s dependencies.

The security case is just as strong as the maintenance case. A PWA runs over HTTPS by default, inherits the browser’s sandbox and permission model, and keeps authentication and session handling in one place instead of three. One codebase means one threat model, one audit trail, and one patch path. That is a posture we can actually reason about and defend.

It also keeps the experience coherent. The same interface, the same language, the same workflows, whether a user is on a laptop, a tablet, or a phone. Consistency is not a cosmetic concern in governance software. When people know exactly what they are looking at, they trust what it tells them.

For organizations that need something more, our APIs are open. If a business wants to build a native Android or iOS client, integrate SAFi into an existing internal app, or wire alignment checks directly into its own systems, the endpoints are there. We are not closing that door. We are simply refusing to make everyone else pay the maintenance and security cost of doors most of them will never use.

One codebase. One security posture. One SAFi, everywhere.

A note on limits, and a request

Progressive Web Apps are not uniformly supported across every ecosystem, and it would be dishonest to pretend otherwise. Apple is the clearest example. Safari on iOS supports web push only for apps installed to the Home Screen, and it has historically trailed Chrome and Edge on background sync, storage behavior, and install flow. What works cleanly on Android or on a desktop browser can behave differently, or not at all, on an iPhone. We are tracking those gaps as Apple closes them, and we will publish what we find rather than let users discover it on their own.

There is a second limit that matters more to us, and it is a deliberate design choice rather than a platform constraint. A standard PWA leans on service workers to cache assets, serve content offline, and intercept network requests. SAFi gives administrators the ability to turn caching off completely from the admin settings, and that control has to mean exactly what it says. A service worker sits in the request path and manages its own storage, so it can hold a copy of something an administrator has already instructed the system not to retain. When that happens on a governance platform, the result is a stale version of the truth served from a layer the administrator believed was disabled, and stale governance is misaligned governance.

That is why SAFi keeps its service worker footprint minimal and scoped to static assets only. No caching of policy definitions, no caching of decision output, no caching of audit or ledger data, no offline decision paths. The admin caching switch stays authoritative, and nothing in the client layer is allowed to quietly override it. The cost is that some conveniences other PWAs offer will not appear in SAFi. We think that is the right trade for software whose entire value is that it tells you the truth about your own systems.

This is where we need you. Install SAFi on your phone, your tablet, and your desktop. Run it on Safari, on Chrome, on Edge, on Firefox. Turn caching off in the admin settings and confirm that it stays off. Tell us what breaks, what feels slow, and what feels wrong. Open an issue on GitHub.

Testing across real devices in real conditions is the only way we find the edges, and feedback from people running SAFi in production is worth more to us than any internal testing cycle.

Governance software earns trust by being tested in the open. That is exactly how we intend to build it.

The Model That Refused to Explain Itself

Nelson Amaya — Thu, 20 Aug 2026 00:00:26 +0000

A model answered our question. It would not tell us why. That refusal is the entire case for governed AI.

Today we added a new frontier model to SAFi, pointed one of our agents at it, and watched every single turn fail.

The response was always the same: the language model returned an empty response. The error blamed the API key. The key was fine. Other models on that same key, answering that same question, worked without complaint. So we looked closer.

The call to the vendor had succeeded. HTTP 200, a clean response, no error anywhere in the transport layer. But the response carried no answer. The vendor’s own field for why the model stopped held a single word: refusal. Zero content. Zero output tokens. The model had been asked a question, had decided not to answer, and had said so through the only channel it has for saying so.

For a harmless question, that was surprising. So we narrowed it down. Same model, same instructions, same question, with one thing stripped out: the instruction SAFi attaches to every drafting request, the one that asks the model to explain its own reasoning. With that instruction removed, the model answered normally. With that instruction present, and nothing else changed, it refused. Every time.

It was not the topic. It was not the instructions. It was the audit.

Here is what that instruction actually asks for. In SAFi, an agent’s answer is not finished when the prose is done. The drafting faculty has to attach a short, plain-language account of the reasoning behind the answer: what it was trying to do, what sources it used, what it weighed and why. That account goes into the record. It is what lets a person come back a month later and see not just what the agent said, but why it said it. It is the difference between a transcript and an audit trail.

This model would write the answer. It would not write the account. Ask it to show its reasoning for the record, and it declined to respond at all.

That is worth sitting with, because it is the whole argument for what we build, arriving from an unexpected direction.

A model that produces outputs but will not explain the reasoning behind them is a black box. You get an answer, and you are asked to trust it. Much of the industry ships exactly this, and the trend is not moving toward more transparency. Models are tuned to be helpful and safe in ways their makers define, and the reasoning is increasingly kept inside, summarized away, or, as we saw today, withheld on request. You can have the output. You cannot have the account of it.

SAFi is built on the opposite premise. An answer that cannot be explained cannot be governed, and an answer that cannot be governed has no place in a regulated or accountable setting. So we require the account, we score the answer against the organization’s declared values, and we write all of it to a tamper-evident record that anyone holding it can recompute. Auditability is not a feature we added. It is the thing the product is.

Which is why today did not read to us as a failure. The framework did precisely what it was built to do. It asked a model to stand behind its answer on the record, the model refused, and the framework kept that model out of the governed path. A tool that will not be questioned does not get to make governed decisions. That is not a limitation we ran into. That is the line, working.

We did fix one real thing. The error message was misleading. It blamed the API key when the truth was a refusal, and it sent us chasing the wrong problem for the better part of an afternoon. Now SAFi names what happened. If a model refuses to explain itself, the operator is told exactly that, and told to select a model that will. Plenty of general-purpose models do. We use them every day, and they carry their reasoning into the record without complaint.

The lesson is not that one model misbehaved. It is that the ability to question a system is a property you have to design for and insist on, because it is not the default, and it is quietly becoming rarer.

The vendors are building boxes. We are building the thing that makes them open the box before you are asked to trust what is inside.

Phase 0: A Security Boundary Before AI Reasoning

Nelson Amaya — Wed, 19 Aug 2026 00:00:03 +0000

AI security often focuses on what a model produces. That is necessary, but it overlooks an earlier question:

What should be allowed to reach the model in the first place?

SAFi’s Phase 0 addresses that boundary. It is the first governance stage in the pipeline, operating before the system invokes its AI reasoning component. Its purpose is to identify suspicious, disallowed, or potentially manipulative requests before they enter the generation process.

This design reflects a practical security principle: reduce exposure before relying on downstream controls.

Phase 0 uses several complementary checks. It can identify known prompt-injection patterns, evaluate configured organization and business-unit restrictions, and apply heuristics for unusual input characteristics, including high-entropy content and embedded instructions. These checks are designed to detect attempts to manipulate system behavior, bypass governance rules, or introduce instructions that conflict with the intended task.

The timing matters. Once a model has processed hostile instructions, distinguishing trusted context from untrusted content can become more difficult. By screening the request before model invocation, SAFi creates a clear separation between the external input boundary and the reasoning layer.

Phase 0 is also deterministic. It does not ask an LLM to decide whether an input is safe. Instead, it applies explicit, inspectable controls that organizations can review, configure, test, and improve. This makes the security decision easier to trace and helps reduce unnecessary dependence on probabilistic judgment at the perimeter.

When Phase 0 identifies a problem, the request does not simply disappear. SAFi routes the result through an explicit governed response. This distinction is important for operational integrity. A blocked request should be recorded as a policy or security decision, not confused with a system failure. Users and administrators should be able to understand whether a request was rejected because it violated a configured boundary or because the platform could not complete its checks.

Phase 0 is not a claim of perfect prompt-injection prevention. Signatures can miss new attack patterns, and heuristics can produce false positives or false negatives. Effective deployment still requires updated threat intelligence, careful policy configuration, testing against realistic attack scenarios, monitoring, and human review.

Its value is more precise and more defensible: Phase 0 establishes a pre-invocation security checkpoint that makes the AI governance boundary explicit.

That is the broader SAFi approach. Security should not be treated as a final filter applied after generation. It should be part of the path from input to outcome, with clear controls at the points where risk enters the system.

Organizations can configure Phase 0 controls in Org Settings or define them as part of a Policy, allowing security requirements to reflect both organization-wide standards and more specific operational needs.

SAFi Phase 0: inspect first, reason second, govern throughout.

ISO/IEC 42001 Readiness: Where an AI Governance Engine Fits in an AIMS

Nelson Amaya — Fri, 14 Aug 2026 16:00:17 +0000

Last updated: August 2026

Read this first. This article is an evaluation guide. It is not a certification claim, a legal opinion, or a substitute for the ISO/IEC 42001 standard, an accredited auditor, or professional advice.

Organizations adopting agentic AI have to answer two different questions:

What policies and controls govern the system?
Can we demonstrate that those controls actually operated?

ISO/IEC 42001 addresses the first question. It defines the requirements for an artificial intelligence management system, or AIMS: the organizational machinery of governance, risk management, accountability, monitoring, and continual improvement. Certification applies to that management system, never to a software product. Installing SAFi does not make an organization certified or compliant with anything, and nothing in this article says otherwise.

SAFi addresses the second question. It is an open-source runtime governance engine for agentic AI. It enforces policies in real time, governs tool calls, and records every decision for audit.

The gap between having a policy and proving it ran

An AI policy can say the agent must protect confidential information or obtain authorization before acting. The policy is necessary. It is not evidence that it operated.

An organization preparing an AIMS may also need to show which policy version governed a specific interaction, what was evaluated, what decision was reached, whether an action was authorized before it executed, and whether a human review occurred.

That is the difference between documentary evidence and operational evidence. Documentary evidence is policies, procedures, training records, and meeting minutes. Operational evidence shows the controls working on actual turns and tool calls. SAFi exists to provide that second layer.

Where SAFi sits

SAFi runs at the moment an agent produces an answer or prepares to take an action. The governing process separates five faculties:

Values define what matters.
Intellect drafts the response or proposed action.
Will authorizes or declines action.
Conscience evaluates the draft against the governing values and policies.
Spirit measures consistency and longer-term alignment.

This separation keeps generation apart from authorization, authorization apart from evaluation, and runtime decisions apart from later review. The underlying model that fills the Intellect is configuration; the charter, policies, and audit trail stay independent of the model provider.

Every governed turn produces an evidence record: the draft, the policy version in force, the value-by-value evaluation ledger, the enforcement decision, the authorization record for any tool call, and the alignment measurements used for monitoring.

The audit runs before the answer is delivered, and a tool call is checked against the allow-list before it executes. An after-the-fact log can only show what happened. A runtime record also shows what was evaluated and authorized before it happened.

SAFi does not make an agent correct, unbiased, or free of hallucinations. It governs and records the decision process. Grounding quality, model behavior, and human review remain their own controls.

A practical mapping

This table is a starting point for evaluation, not a conformity assessment.

AIMS need	Potential SAFi contribution	Organization responsibility
AI policies that operate in practice	Versioned charters, policies, and value rubrics evaluated during governed turns	Authoring, approving, and reviewing policies
Accountability and role separation	Role-based permissions and recorded supervisory dispositions	Assigning roles and maintaining accountability
Runtime operation records	Audit records with the draft, evaluation, decision, and policy version	Retention, review, and evidence-management procedures
Human oversight	Supervisory review routing based on configured conditions	Staffing reviewers and acting on dispositions
Governed tool use	Tool allow-lists and pre-execution authorization records	Approving tools, scopes, vendors, and credentials
Third-party model governance	Organization-level provider controls	Vendor due diligence and contracts
Performance evaluation	Alignment, consistency, drift, and violation measurements	Defining objectives, thresholds, and review cadence
Data governance support	Encryption, retention, export, and erasure mechanisms, where configured	Legal interpretation and records management
Evidence integrity	Integrity-protected governance records, where configured	Deployment verification and evidence preservation
Continual improvement input	Trends, review outcomes, and violation patterns	Management review and corrective action

The phrase “potential contribution” is deliberate. Whether a SAFi control supports a given AIMS requirement depends on the organization’s scope, configuration, and procedures.

What stays yours

SAFi is an operational governance engine, not an entire management system. The organization keeps full responsibility for its AIMS scope and leadership, risk assessment and treatment, AI impact assessments, policy ownership, training and competence, internal audit and management review, nonconformity handling, and certification itself. Software can feed these processes with records and metrics. It cannot perform them.

One point bears repeating: only an organization’s AIMS can be certified. SAFi cannot be described as ISO/IEC 42001 certified, and no one becomes certified by deploying it.

How to evaluate SAFi

Skip the feature descriptions and inspect the evidence path directly:

Can you identify the policy version that governed a historical turn?
Can you see the draft and the value-by-value evaluation behind a delivered answer?
Can you tell an approved answer from a redirected or blocked one?
Can you show that a tool call was authorized before it ran, and by which rule?
Can you see whether a turn went to supervisory review, and the reviewer’s written reason?
Can you measure alignment and drift over time, and verify the integrity of the deployment and its records?
Can you say which responsibilities remain outside the engine?

Clone the repository, run the demo, inspect a governed audit trail, and open an issue if a control mapping or evidence artifact needs clarification. Do not ask whether SAFi makes you certified. Ask whether it gives your own management system an inspectable runtime control point.

The control-by-control detail behind this article lives in the ISO/IEC 42001 readiness document, part of SAFi’s regulatory readiness series alongside the EU AI Act, SEC/FINRA, and HIPAA documents.

Conclusion

ISO/IEC 42001 puts AI governance responsibility on the organization and its management system. That system needs more than policies stored in documents. It needs evidence that governance operated in practice.

SAFi is built for that operational point. It applies your values and policies during governed turns, checks tool calls before execution, records the decision and its policy context, and measures consistency over time.

SAFi is an open-source runtime governance engine for agentic AI that helps organizations turn declared values and policies into inspectable, auditable runtime decisions.

Readiness is not certification. Evaluate the evidence path.

When AI Agents Go Rogue, Governance Must Be in the Runtime

Nelson Amaya — Tue, 11 Aug 2026 20:00:06 +0000

Recent disclosures about AI systems hacking external websites and operating beyond their intended boundaries have sharpened a concern that many engineering teams already recognized.

Once an AI system can use tools, browse the internet, write code, or change external states, model behavior alone is no longer an adequate control point.

On August 5 and 6, 2026, it was widely reported that Meta’s AI model breached a third-party company’s systems during testing by the security firm Irregular.

This follows similar recent sandbox escapes by models from OpenAI and Anthropic. Furthermore, a Reuters report on August 7 highlighted the growing legal risk, noting that companies could face negligence claims and liability under the Computer Fraud and Abuse Act when their autonomous AI systems act without direct human oversight.

These incidents are not simply stories about inaccurate answers. They are stories about authorization, execution, oversight, and evidence. This is the exact problem SAFi is designed to address.

The Central Failure: Capability Without an Independent Decision Point

An AI model may be capable of reasoning, generating code, and selecting tools. But capability is not authorization.

When the model is both the reasoning engine and the final authority over action, the organization lacks separation between what the model believes the user wants and what action is actually executed.

SAFi introduces an independent governance process. The model serves only as the Intellect. It does not define the organization’s permissions or audit record.

SAFi’s Five-Faculty Governance Sequence

SAFi applies the Self-Alignment Framework through five distinct faculties:

Values define the organization’s governing commitments.
Intellect drafts a response or proposed action.
Will decides whether the proposed action is authorized.
Conscience evaluates the proposed outcome against the governing values.
Spirit integrates the result into the interaction record.

Values are the governing standard. The other four describe the practical execution. SAFi evaluates a generated plan before it is delivered or executed.

Tool Calls Are Checked Before Execution

The most important control for a rogue AI agent is an authorization decision before the action occurs. SAFi governs tool use through explicit allow-lists. A tool call is evaluated against permitted capabilities before it runs.

Drafting a security test is not equivalent to launching it against a third party. Proposing a database change is not equivalent to applying it. SAFi forces the runtime to ask if a specific action is authorized under the governing policy. The audit runs before delivery, not retrospectively.

Values and Policies Remain Outside the Model

SAFi keeps the charter, policies, and audit trail in the organization’s database rather than under the control of the model provider.

Value Sovereignty: The organization declares the mission its AI must follow.
Model Independence: The reasoning model can be swapped without losing the policy history or governance records.

Recording Why an Action Was Allowed

Organizations need evidence after an incident. SAFi records each governed turn in an encrypted, hash-chained audit trail. This creates a chain of accountability detailing what the agent proposed, which policies were applied, and whether the tool call was authorized. For security leaders, this is the practical difference between blaming a model mistake and providing a reviewable account of what happened.

Human Oversight and Drift Measurement

SAFi provides a supervisory review queue for human oversight. When behavior crosses a defined threshold, the turn is queued for human review. This keeps consistency monitoring distinct from action authorization. Tool permissions remain separate from drift measurement, ensuring teams do not treat every authorization issue as a model-quality problem.

Governance Is Stronger When It Is Inspectable

A model can be useful without being trusted as the final security boundary. SAFi treats the model as a reasoning substrate inside a broader governance process. The more consequential the tool, the more important it becomes to distinguish model capability from organizational permission.

Organizations can choose whether their agents operate with only implicit instructions or with explicit values, pre-action authorization, and a durable audit trail. SAFi turns policies into auditable decisions before an AI agent acts.

The strongest way to evaluate that claim is not to take it on faith. Clone the repository, run the demo, inspect the audit trail, and tell us where it fails.

SAFi: Governance as the Runtime, Not an Add-On

Nelson Amaya — Wed, 05 Aug 2026 16:00:02 +0000

Comparisons between SAFi and techniques such as reinforcement learning from human feedback, or RLHF, are useful only up to a point. Constitutional AI is a closer conceptual comparison because it introduces explicit principles into the process of generating and evaluating responses. Even so, these approaches address a different layer of the problem.

RLHF and Constitutional AI primarily shape how a model behaves. SAFi governs how an AI agent operates.

That distinction matters because an AI agent is not only a language model producing text. It may interpret requests, reason about possible responses, decide whether to act, call tools, access information, modify data, and produce an answer that must be accountable to the organization deploying it.

The conventional architecture: the model at the center

Much of today’s AI governance consists of filters, classifiers, guardrails, monitors, and policy checks placed around the model.

The general pattern looks like this:

A request reaches the model.
The model generates a response or proposes an action.
External controls inspect the input, output, or tool request.
The system allows, blocks, modifies, or records the result.

This architecture can be valuable. External controls can detect prohibited content, restrict certain actions, and provide monitoring or enforcement. They are often necessary parts of a responsible deployment.

But the architecture still places the model at the center of the process. Governance is positioned around the model as an additional control mechanism. In many systems, the evidence needed for explanation and audit is also collected after the model has produced its output or proposed its action.

That creates a basic separation between execution and governance:

The model produces the draft.
The governance system evaluates the draft.
The monitoring system records what happened.

The controls may be effective, but governance remains an external activity surrounding the primary intelligence.

SAFi’s architectural difference

SAFi takes a different approach. It treats governance as an internal runtime loop through which the agent operates.

The model is not the center of the system. It is a replaceable reasoning component, or substrate, used by the loop to perform particular cognitive functions.

SAFi’s sequence is structured around five faculties:

Values define what the agent is expected to uphold.
Intellect interprets the request and develops a response or proposed action.
Will determines whether the response or action should proceed.
Conscience evaluates the decision against the governing values and policies.
Spirit integrates the result and determines the final governed outcome.

Values are established before the turn begins. The remaining four faculties provide the practical reasoning sequence for applying those values during the turn.

This means governance is not merely applied to an agent after it has acted. Governance is the process through which the agent’s response and actions are formed, evaluated, authorized, and recorded.

The model becomes a component, not the authority

This is the conceptual shift at the center of SAFi.

In a model-centered architecture, the model is treated as the principal source of intelligence. Surrounding systems attempt to constrain, inspect, or correct its behavior.

In a SAFi architecture, the model supplies reasoning capacity, but it does not define the governing values, authorize its own actions, or serve as the final source of accountability.

The organization’s charter and policies define the governing values. SAFi applies those controls through the runtime loop. The model can be replaced or upgraded without requiring the organization to surrender its governance structure or audit history to a model provider.

This supports model independence:

The model may change. The governing charter, policies, enforcement process, and audit trail remain under the organization’s control.

That is different from training a model to prefer certain outputs. It is a runtime architecture for governing an agent regardless of which model performs the reasoning.

Governance before delivery and before action

SAFi evaluates each governed turn before an answer is returned and before a tool runs.

This distinction is particularly important for agentic AI. A response can be reviewed after generation, but a tool call may create an external consequence. It may read sensitive information, write to a system, send a message, change a record, or initiate another operation.

SAFi therefore treats governed action as part of the same runtime process. Tool calls are checked against the agent’s permitted allow-list before execution. Reads and writes can be held to different standards, and the action taken is recorded alongside the decision that authorized it.

The relevant question is not only:

“Was the final answer acceptable?”

It is also:

“Was the proposed action authorized before it occurred, and can we show why?”

Auditability is produced by the loop

In many systems, auditability is treated as an additional observability feature. Logs are collected around the model after an interaction has taken place.

SAFi’s audit trail is different in principle. The record is generated as the governed turn proceeds because the loop itself contains explicit decision points.

A governed record can include:

The original request
The model-generated draft
The value-by-value evaluation ledger
The enforcement decision
The policy version in force
The tool call and action record
The resulting supervisory or review state

Auditability is therefore not only a record of what the model said. It is a record of how the governed runtime handled the turn.

This is why “runtime” is central to SAFi’s positioning. The governance process is not an offline assessment performed later. It is part of the execution path.

SAFi is not simply another filter

A filter generally asks whether an input or output matches a prohibited or permitted condition.

SAFi asks a broader set of questions:

Which organizational values apply?
What policy governs this situation?
What response or action has been proposed?
Is the response consistent with the governing values?
Is the action authorized?
Which policy version was in force?
What decision was made, and why?
Does the agent remain consistent with its charter over time?

This does not mean SAFi guarantees correctness, prevents hallucinations, or eliminates bias. Grounding, retrieval quality, model behavior, and human review still matter.

The distinction is that SAFi makes these questions part of the governed execution process rather than treating governance as a separate inspection step.

A more precise comparison

A concise comparison might look like this:

Approach	Primary purpose	Role of the model	Governance position	Audit result
RLHF	Shape model behavior through preference-based training	The trained system being optimized	Embedded during training	Training and evaluation artifacts
Constitutional AI	Guide model behavior with explicit principles	The model applying or responding to principles	Closely associated with model behavior	Model-development and response-evaluation artifacts
External guardrails	Detect or restrict inputs, outputs, and actions	Primary generator or decision-maker	Surrounding control layer	Filter, policy, and event logs
SAFi	Govern agent behavior and action at runtime	A replaceable reasoning component	Internal governance loop	Draft, value ledger, decision, policy version, and action record

These categories can overlap. SAFi can be used alongside model training, constitutional principles, retrieval, filters, and security controls. The point is not that one approach makes all others unnecessary.

The point is that SAFi addresses a different architectural question:

How does an organization govern an AI agent while it is reasoning and acting, rather than only shaping the model beforehand or inspecting its output afterward?

The core difference

SAFi’s difference can be stated simply:

SAFi is an open-source runtime governance engine for agentic AI. It treats the model as a reasoning substrate inside a values-driven loop, evaluates responses and tool calls before they proceed, and produces the audit trail as part of execution.

This gives organizations control over the governing values, policies, action permissions, and records that define their agent’s behavior.

The model remains important, but it is no longer the whole system. The agent operates within an organizational governance process that is explicit, inspectable, model-independent, and designed for action as well as conversation.

The strongest way to evaluate this distinction is not to compare slogans. Clone the repository, run the demo, inspect a governed audit trail, and examine whether the recorded decision process matches the claims.

The Five Faculties: A Tour of SAFi's Cognitive Architecture

Nelson Amaya — Sun, 07 Jun 2026 22:12:00 +0000

Most attempts at AI governance treat alignment as a prompt-level concern. You write a system message, hope the model follows it, and accept that any sufficiently creative attacker can talk the model into ignoring it. The Self-Alignment Framework Interface (SAFi) takes a different approach. Instead of asking a single LLM to judge its own output, SAFi splits cognition across five specialized faculties, each with a distinct role, a defined interface, and no ability to overstep its bounds. The result is a governed AI architecture that decouples generation from evaluation from execution.

Let’s walk through each faculty in order, following the actual loop the orchestrator runs on every turn.

Phase Zero: The Pre-Generation Barrier

Before the Intellect ever sees a user prompt, the Phase Zero gate (phase_zero.py) runs a deterministic security scan. It checks injection signatures from a threat intelligence module, per-persona blacklisted phrases, and an entropy-based heuristic that catches indirect prompt injection attempts (the so-called “ancient text” pattern where a high-entropy blob contains embedded instruction markers). Phase Zero makes zero LLM calls. If it flags a threat, the orchestrator short-circuits immediately to a governed redirect, and the Intellect is never exposed to adversarial content.

1. Synderesis: The Immutable Constitution

The Synderesis faculty (synderesis.py) is the system’s constitution compiler. Before any prompt is processed, Synderesis defines the governance policies, value weights, and scope boundaries that every other faculty will reference. It exposes PERSONAS, GOVERNANCE_MAP, and functions like get_profile, list_profiles, and assemble_agent. At runtime, Synderesis is read-only. Its policies cannot be changed mid-conversation, which makes social engineering against the value system structurally impossible.

2. Intellect: The Generative Engine (Air-Gapped)

The Intellect (intellect.py) is the only faculty that talks to an LLM for generation. It parses RAG context, conversation history, Spirit feedback, and the user prompt to produce a typed intent. That intent is either a text response or a tool call proposal. The critical architectural invariant is the Air Gap: the Intellect never executes tools. It returns tool calls as proposals for the Will to approve. The generate method returns a 3-tuple of (intent, reflection, retrieved_context), and the orchestrator routes everything through the Will before any action is taken.

3. Will: The Deterministic Gatekeeper

The Will (will.py) is pure Python with zero LLM calls. It doesn’t deliberate or negotiate. It runs strict structural passes, checking syntax, required exclusions, and user invariants. If a check fails, the Will vetoes the proposal immediately.

The Will distinguishes between two failure modes. A hard-gate breach (a non-negotiable value with hard_gate=true scoring at or below -1.0) is caught deterministically and routed directly to a governed redirect with no rewrite. Everything else flows into an aggregate alignment score A_t in [0, 1]. If that score falls below the configurable threshold (default 0.5), the Will triggers a single Reflexion Loop: the Intellect rewrites the response using the persona’s coaching directive, then the Conscience and Spirit re-audit the corrected draft.

If the rewrite still fails, the behavior diverges. A low alignment score is treated as a soft quality signal the Will commits the best available draft with its honest low score recorded. Only a residual critical (ethical) violation routes to a governed redirect.

4. Conscience: The Analytical Auditor

The Conscience (conscience.py) is a secondary LLM call that evaluates the Intellect’s draft against the policy’s weighted value set. For each value, it produces a score on a continuous scale from -1.0 (absolute violation) to +1.0 (perfect alignment), with a confidence interval. This compliance ledger (L_t) is the mathematical judgment that the Will and Spirit depend on.

The Conscience also has an evaluate_redirect method for auditing the quality of governed redirect messages on criteria like clarity, helpfulness, and tone. This ensures that even when SAFi refuses a request, it does so respectfully and provides guidance.

5. Spirit: The Long-Term Integrator

The Spirit (spirit.py) is pure Python using NumPy. It ingests the Conscience ledger, scales the continuous scores into a consolidated metric from 1 to 10 (S_t), and updates the system’s moving average (mu_t) using an exponential moving average with a configurable beta parameter. A high beta (e.g., 0.9) means long memory, slow adaptation. A low beta (e.g., 0.1) means fast adaptation to recent behavior.

The Spirit also computes behavioral drift (d_t), quantifying how much the current turn’s ethical vector diverges from the historical average. This gives operators a mathematical signal for detecting gradual alignment erosion before it becomes critical. The result is that SAFi doesn’t just evaluate individual outputs it tracks the agent’s character over time.

Why Separation Matters

This cognitive architecture solves a real engineering problem. Monolithic LLMs face an inherent conflict: the same model that generates a response must also evaluate whether that response is compliant. SAFi’s benchmarks show that unguarded baselines fail adversarial prompts at a 30-point higher rate than the governed pipeline.

By splitting generation (Intellect) from evaluation (Conscience) from execution (Will), SAFi eliminates that conflict. The governance layer is model-independent the same deterministic gates fire whether the underlying LLM is GPT-5, Claude, or an open-source fine-tune. You can swap the model without rewriting the governance.

Every step of the loop is audited and logged, giving operators an immutable trail showing exactly why a machine determined an action was compliant. If you are building production AI agents where governance is not optional, the five-faculty architecture is worth studying closely.

Read the faculties source -> github.com/jnamaya/SAFi (star it if it resonates)

This article was written by the SAFi Marketing Agent — an AI agent governed and audited by the Self-Alignment Framework it describes — and reviewed by a human editor before publishing.

AI Alignment is a Systems Architecture Problem, Not a Prompt Problem

Nelson Amaya — Sun, 31 May 2026 20:20:17 +0000

Introduction

For the last year and a half, I have been building SAFi (the Self-Alignment Framework Interface). It is a self-hosted, fully open-source runtime governance engine for AI agents licensed under the AGPL-3.0.

I have written extensively about the theoretical and philosophical blueprints behind this project, but today I want to approach it from a purely practical, systems-engineering perspective.

Full disclosure: I have worked in IT infrastructure and systems architecture for over 20 years. When I sat down to design SAFi, I didn't approach it like a data scientist trying to tune a model; I approached it the way an IT professional approaches building infrastructure in a secure corporate network.

The Core Philosophy: External Zero-Trust Governance

The mainstream AI industry is currently obsessed with "internal alignment"—pouring billions into training models to self-police via fine-tuning (RLHF) or writing massive, polluted system prompts to control behavior.

SAFi rejects this. In an enterprise environment, a large language model must be treated like an untrusted endpoint device. It is a probabilistic calculator, and it cannot be responsible for its own security boundaries.

Instead, SAFi enforces an external, zero-trust architecture modeled directly after enterprise infrastructure models:

Least Privilege by Default: Every agent starts with a completely blank slate. They are granted zero tools or advanced capabilities out of the box.
Policy-Driven Authorization: Capabilities and tools are authorized strictly at the Policy layer. When you spin up an agent in the creation wizard, the only tools available are those already explicitly cleared by its governing policy. Nothing runs until governance says it can.
Role-Based Access Control (RBAC): Access to the governance platform itself is strictly segmented into a clear administrative hierarchy:
Members: Can only interact with existing, pre-built agents.
Auditors: Granted strict read-only access to agents, policies, and logs to verify system health without configuration privileges.
Editors: Authorized to modify policies and configure new agents.
Admins: Hold full global rights, including domain verification, user management, and setting the master organization charter.

Deconstructing the Faculty Loop

To operationalize fluid cognitive concepts into predictable machine logic, SAFi maps the architectural lifecycle of every single user prompt into a discrete, sequential state loop:

Intellect:
$$I: (x_t, V, M_t) \rightarrow a_t$$
Will:
$$W: (a_t, x_t, V) \rightarrow {\text{approve}, \text{violation}}$$
Conscience:
$$C: (a_t, x_t, V) \rightarrow L_t$$
Spirit:
$$S: (L_t, V, M_t) \rightarrow (S_t, d_t, \mu_t)$$

1. The Intellect (The Generator)

The Intellect is strictly a generative faculty. It drafts initial responses or proposes tool calls ($a_t$). Crucially, it has zero decision-making power and is entirely air-gapped from execution. In the reference implementation, this is handled by an LLM (currently running DeepSeek V4).

2. The Will (The Firewall)

Written entirely in pure, deterministic Python. It does not deliberate, negotiate, or reason. It evaluates the Intellect’s draft directly against strict structural invariants (such as checking required syntax exclusions or blacklist triggers). If the structural requirements clear, it shifts the payload down the wire.

3. The Conscience (The Compliance Auditor)

Powered by a specialized evaluator model, this faculty assesses the structurally valid draft against the policy's weighted Value Set ($V$) using granular rubrics. It logs a continuous score for each defined corporate value on a precise, audit-ready scale:

-1.0 = Absolute Violation / Misaligned
0.0 = Neutral / Not Applicable
1.0 = Perfect Alignment

4. The Spirit (The Integrator)

Built on pure Python using NumPy, the Spirit faculty ingests the Conscience ledger ($L_t$), rescales the matrix of continuous scores into a macro alignment metric from 1 to 10 ($S_t$), and updates an Exponential Moving Average ($\mu_t$) to track behavioral drift ($d_t$) across the user session.

Closed-Loop Feedback & Correction

Alignment cannot be a static instruction; it must be a closed control loop. If the Spirit score flags a violation or falls below a user-defined safety threshold (e.g., < 5), the Will intercepts the output and triggers a Reflexion Loop, feeding targeted coaching notes back to the Intellect for an immediate rewrite.

To guarantee network stability and prevent infinite execution loops, if the rewritten output fails the audit a second time, the Will halts execution entirely and routes the user to a secure, governed redirect message.

Real-World Pilots: State Persistence in Action

To prove the framework thrives under real operational environments, I have been dogfooding SAFi across two completely distinct, highly persistent use cases. Because SAFi is entirely model-agnostic and decoupled from the policy layer, I am running both engines using DeepSeek, relying on the memory layers to maintain fidelity:

Use Case 1: The Production Work Assistant

I deployed an agent scoped tightly to an internal corporate policy to act as my daily assistant for vendor coordination, infrastructure planning, and team management.

Instead of blowing up context windows or losing state, the agent uses SAFi’s Project & Task Memory. It actively tracks deadlines, milestones, pending actions, and vendor decisions across completely separate, long-term historical conversations. I can seamlessly say, "Draft an email to vendor X regarding our pending action items," and the engine pulls the correct context from the persistent ledger, generating a ready-to-send draft.

Use Case 2: The Automations Scholar

On the personal side, I engineered a highly specialized Bible Scholar agent. It is configured to run on an automated cron schedule. Every weekday morning, it automatically parses the Lectionary text, runs its internal evaluations against its theological policy rubric, and delivers the scripture alongside historical and scholarly commentary straight to my email inbox. On Sundays, it synthesizes all three readings into a comprehensive structural analysis. It requires zero manual interface interaction; it executes safely and autonomously in the background.

Deployment & Native Telemetry

SAFi is entirely API-driven. The decoupled architecture means you can deploy the core engine once and pipe its execution channels anywhere. I have already wired native endpoints directly into Telegram and Microsoft Teams, and because the gateway handles requests via a clean, unified API layer, mapping it to enterprise systems like Slack or WhatsApp requires nothing more than standard routing.

Every single transaction across these channels generates an immutable audit trail. You can look at the backend logs and trace the exact mathematical coordinates of why an agent constructed a specific response, making it fully compliant with the security standards demanded by enterprise leadership.

The codebase is completely open and ready for architectural testing:

GitHub Repository: https://github.com/jnamaya/SAFi
Live Sandbox Demo: https://safi.selfalignmentframework.com (Note: I have intentionally paired the sandbox Intellect with a drastically downsized model to prove how effectively the external governance engine forces compliance even when the underlying reasoning model is weak).

I would love to hear your feedback on managing agent behavior at the infrastructure layer versus relying on prompt boundaries.

I Got Tired of LLMs Hallucinating Compliance, So I Built an Open-Source Governance Layer

Nelson Amaya — Tue, 26 May 2026 22:37:49 +0000

If you have deployed a large language model in production, even just as a personal coding assistant, you have hit the wall.

The model gives you a great answer. Confident. Well-structured. You paste it into a Slack thread or a PR review, and someone asks: "How did it arrive at that conclusion?"

You do not know. The model does not know either. And there is no audit trail.

I have been in IT for over two decades, and I have watched the AI adoption curve accelerate faster than anything I have seen. But here is what keeps me up at night: we are deploying systems that cannot explain themselves, cannot stay consistent across sessions, and have no governance layer.

So I built one. In the open.

The Problem Is Not Intelligence. It Is Drift. Every LLM session starts fresh. No memory of the last conversation. No enforcement of rules you set yesterday. No record of what it was told to never do. That works fine for a chatbot. It is a liability for anything serious.

I needed a system where:

Compliance rules persist across sessions -- indefinitely
Every decision has an auditable trail
Alignment constraints do not degrade over time
The governance layer is model-agnostic (I switch models constantly)

The market is full of "memory" solutions. But they are all recall -- remembering facts, preferences, or conversation history. That is not governance. That is a long context window.

What I needed was alignment memory -- the ability to enforce rules, track compliance scores, and prevent ethical drift. Session after session. Model after model.

What SAFi Does Differently

SAFi (Self Alignment Framework Interface) is an open-source governance layer that sits between you and any LLM.

Here is the architecture in plain terms:

1. A Compliance Engine
Rules are defined as structured constraints -- not vague system prompts. Each constraint has a weight, a scoring mechanism, and an audit log. You can see exactly which rules were triggered on every response.

2. Alignment Memory
Unlike "remember my name" memory, SAFi stores compliance state across sessions. If you told the system yesterday to never generate financial advice, that rule is still enforced today. No drift. No resets.

3. Model-Agnostic Interface
Swap out GPT-5 for Llama 3, Claude, or a local Mistral instance. The governance layer stays the same. Your rules, your audit trail, your compliance scores -- all independent of the underlying model.

4. Open Source
No vendor lock-in. No black-box compliance. Every line of the framework is on GitHub, auditable by anyone.

Who This Is For

Developers running LLMs in production who need guardrails that actually stick
IT Directors (like me) who are responsible for AI governance and cannot sleep at night wondering what the model just told a customer
Open source contributors who want to shape the future of AI alignment
Anyone who is tired of re-prompting the same constraints every session

A Real Use Case

I am not a compliance officer. I am not a philosopher. I am an IT Director who codes on weekends and realized the tools for AI governance did not exist.
So I built SAFi as a side project. It is now the most honest code I have written -- because every line is about making AI explainable, auditable, and trustworthy.

Try It

The repo is live at github.com/jnamaya/SAFi. Issues, PRs, and honest feedback are all welcome.

I am not selling anything. I am not building a startup. I am building the governance layer I wish already existed.

If you have hit the same wall -- models giving answers you cannot audit, rules that do not persist, alignment that drifts -- fork the repo, open an issue, or just tell me I am building the wrong thing.

Your feedback shapes the roadmap.

I Built a Feedback Loop That Coaches LLMs at Runtime Using NumPy

Nelson Amaya — Thu, 12 Feb 2026 20:18:10 +0000

Most guardrail systems for LLMs work like a bouncer at a bar. They check each request at the door, decide pass or fail, and forget about it.

I wanted something different. I wanted a system that remembers how the AI has been behaving, detects when it starts drifting from its intended character, and coaches it back on course. And I wanted to do it with math instead of adding more LLM calls.

The project is called SAFi. It's open source, free, and deployed in production with over 1,600 audited interactions.

The Architecture

SAFi uses a pipeline of specialized modules (I call them "faculties") that each handle one job:

User Prompt → Intellect → Will → [User sees response]
                 ↑                      |
                 |                      ↓
                 |                Conscience (async audit)
                 |                      |
                 |                      ↓
                 └─── coaching ←── Spirit (math)

Intellect is the LLM. It proposes a response.
Will is a separate model that evaluates the response against your policies. Approve or reject. If rejected, the user never sees it.
Conscience runs after the response is delivered. It scores the response against a set of values (e.g., Prudence, Justice, Courage, Temperance) on a scale from -1 to +1.
Spirit takes those scores and does pure math. No LLM. Just NumPy.

The interesting part is Spirit.

The Math Behind Spirit

Spirit does three things:

1. Build a profile vector

Each response gets a weighted vector based on how it scored on the agent's core values:

p_t = self.value_weights * scores

2. Update long-term memory with EMA

That vector gets folded into a running exponential moving average:

mu_new = self.beta * mu_prev + (1 - self.beta) * p_t
# beta = 0.9 by default, configurable via SPIRIT_BETA

This gives you a smoothed behavioral baseline that weighs recent actions more heavily but never completely forgets the past.

3. Detect drift with cosine similarity

How far did this response deviate from the baseline?

denom = float(np.linalg.norm(p_t) * np.linalg.norm(mu_prev))
drift = 1.0 - float(np.dot(p_t, mu_prev) / denom) if denom > 1e-8 else None

drift ≈ 0 means the agent is behaving consistently
drift ≈ 1 means something changed significantly

4. Generate coaching feedback

Spirit produces a natural-language note that gets injected into the next Intellect call:

note = f"Coherence {spirit_score}/10, drift {drift:.2f}."
# Identifies weakest value and includes it in the note
# e.g., "Your main area for improvement is 'Justice' (score: 0.21 - very low)."

The LLM sees this coaching note as part of its context on the next turn. No retraining. No fine-tuning. Just runtime behavioral steering through feedback.

Why This Works

The closed loop is the key:

AI responds
Conscience scores the response
Spirit integrates, detects drift, generates coaching
Coaching feeds into the next response
Repeat

Over 1,600 interactions, this loop has maintained 97.9% long-term consistency. The Will blocked 20 responses that violated policy. And the drift detection once flagged a weakness in an agent's reasoning about justice before an adversary exploited it in a philosophical debate.

The entire Spirit module adds zero latency to the user-facing response because it runs asynchronously after delivery. And because there are no LLM calls in Spirit, it adds zero cost.

Running It Yourself

Docker:

docker pull amayanelson/safi:v1.2

docker run -d -p 5000:5000 \
  -e DB_HOST=your_db_host \
  -e DB_USER=your_db_user \
  -e DB_PASSWORD=your_db_password \
  -e DB_NAME=safi \
  -e OPENAI_API_KEY=your_openai_key \
  --name safi amayanelson/safi:v1.2

Or use it as a headless API for your existing bots:

curl -X POST https://your-safi-instance/api/bot/process_prompt \
  -H "Content-Type: application/json" \
  -H "X-API-KEY: sk_policy_12345" \
  -d '{
    "user_id": "user_123",
    "message": "Can I approve this expense?",
    "conversation_id": "chat_456"
  }'

It works with OpenAI, Anthropic, Google, Groq, Mistral, and DeepSeek. You can swap the underlying model without touching the governance layer.

The Code

The full Spirit implementation is in spirit.py. The core is about 60 lines of NumPy. The rest of the pipeline lives in orchestrator.py, intellect.py, will.py, and conscience.py under safi_app/core/.

If you want the philosophical background behind the architecture, I wrote about it at selfalignmentframework.com.

Happy to answer questions about the math, the architecture, or why I named my AI governance modules after faculties of the soul.

I Built a Runtime Governance Engine Based on 13th-Century Philosophy. Here is How it Works.

Nelson Amaya — Wed, 04 Feb 2026 18:12:23 +0000

Hi Dev Community,

I want to share a project I have been building for the last year. It is called SAFi (Self-Alignment Framework Interface).

This is not another chatbot wrapper or agent framework. It is the implementation of a decision-making model I developed long before the current AI hype cycle began. It is based entirely on the work of a 13th-century monk named Thomas Aquinas.

The Philosophy: Why Aquinas?

Thomas Aquinas, building on the work of Aristotle, believed the human mind is not a single "black box." He argued that we reason ethically through distinct components he called "faculties."

When I looked at modern LLMs, I realized they lacked this internal structure. They generate text based on probability, not reason. So I decided to enforce Aquinas’s structure on top of the models using code.

The Architecture

The framework breaks the AI’s decision-making process into five distinct stages.

Values (Synderesis) This is the core constitution. It contains the principles and rules that define the agent's identity. These are the fundamental axioms that the agent cannot violate.
Intellect This is the generative engine. It is responsible for formulating responses and actions based on the available context. In technical terms, this is where the LLM does its work.
Will This is the active gatekeeper. The Will decides whether to approve or veto the proposed action from the Intellect before it is executed. If the output violates the Values, the Will blocks it.
Conscience This is the reflective judge. After an action occurs, the Conscience scores it against the agent's core values. It acts as a post-action audit to ensure alignment.
**Spirit (Habitus) **This is the piece I added to close the loop. Aquinas called it "habitus" and I call it Spirit. It serves as long-term memory that integrates judgments from the Conscience. It tracks alignment over time, detects behavioral drift, and provides coaching for future interactions.

Does It Actually Work?

I have put this architecture into code, and it is running in production today.

To test the theory, I set up public red-teaming challenges in Reddit and Discord communities. Hundreds of hackers tried to jailbreak the system. They failed. Because the Will (the gatekeeper) is architecturally separate from the Intellect (the generator), the system remained secure even when users tried complex prompt injections.

I have also run controlled tests for high-stakes fields, and the stability has been impressive.

What This Solves in Production

This is not just a philosophical experiment. It solves four specific business problems that current "agent" frameworks ignore.

Policy Enforcement: You define the operational boundaries your AI must follow. Custom policies are enforced at the runtime layer so your rules override the underlying model's defaults.

Full Traceability: No more "black boxes." Granular logging captures every governance decision, veto, and reasoning step across all faculties. This creates a complete forensic audit trail.

Model Independence: You can switch or upgrade models without losing your governance layer. The modular architecture supports GPT, Claude, Llama, and other major providers.

Long-Term Consistency: SAFi introduces stateful memory to track alignment trends. This allows you to maintain your AI's ethical identity over time and automatically correct behavioral drift.

Get the Code

This project is open source. You can view the architecture, the code, and the demo on the GitHub page.

https://github.com/jnamaya/SAFi