keep AI-generated outputs non-authoritative: provider responses, critic reports, retrieval results, risk scores,

previews, and action proposals can inform a human reviewer, but cannot themselves authorize execution or writes.

The project develops and validates a practical safety architecture built around explicit human approval, hash-bound

action proposals, fail-closed gates, and append-only audit evidence. Funding will support focused engineering,

adversarial testing, reproducible offline validation, and public documentation of the system’s authority

boundaries.

The intended public benefit is reusable safety infrastructure for developers and researchers building AI-assisted

tools: a concrete reference implementation showing how to separate model suggestions from consequential authority,

rather than treating model output, scoring, or guardrails as permission. AIOA does not provide autonomous

execution, provider-driven control, or automatic approval.

What are this project's goals? How will you achieve them?

The project’s goal is to create and validate an open-source safety architecture for AI-assisted systems in which

model outputs never become authority by default. It will demonstrate how AI suggestions, risk classifications,

critic feedback, retrieval results, and proposed actions can remain useful to a human operator while consequential

actions—such as writes or controlled execution—remain behind explicit, verifiable human approval.

We will achieve this by developing a local-first reference implementation with four core mechanisms: inert action

proposals and previews; explicit, hash-bound human approval for each consequential action; fail-closed policy gates

that reject missing or mismatched authorization; and append-only audit records that preserve evidence of what was

proposed, reviewed, approved, or denied. The work will include focused engineering, adversarial and regression

tests, reproducible offline validation, and clear public documentation of the system’s capabilities and limits.

The outcome will be a reusable, inspectable reference for developers and researchers who want to build AI-assisted

tools without confusing model output, automated scoring, or safety guardrails with permission to act

How will this funding be used?

Funding will be used to move the project from development on limited netbook hardware to a reliable, reproducible

research and engineering environment.

The primary costs are:

- Workstations and essential hardware for secure local development, testing, offline validation, and reproducible

builds.

- API and compute credits for controlled, human-supervised evaluation of different AI models and safety-relevant

behaviours. Model access will be used for testing and comparison; it will not create autonomous authority or

automatic execution.

- Secure storage, backups, and development infrastructure needed to preserve audit evidence, test artifacts, and

reproducible releases.

- Focused engineering time for implementation, adversarial testing, documentation, and open-source maintenance.

The funding will directly strengthen the project’s ability to test safety boundaries under realistic conditions,

publish reproducible results, and make the resulting reference implementation useful to other developers and

researchers.

Who is on your team? What's your track record on similar projects?

AIOA–NiFe spArk HAT is my original, founder-led project. I currently lead its architecture, implementation, safety

design, testing, and documentation.

I am also working to build a small international team with a collaborator based in Ireland. The team is still

forming, so I remain accountable for the project’s technical direction and delivery. As the project develops, I

plan to bring in complementary expertise for engineering, evaluation, research review, and community or partnership

work.

My track record is primarily hands-on: I have independently designed and developed AIOA’s local-first safety

architecture, including explicit human approval boundaries, hash-bound action proposals, fail-closed gates, audit

evidence, and deterministic offline validation. I have also developed multiple related technology projects, which

are collected at These projects reflect an ongoing focus on responsible AI, practical

safety controls, local-first systems, and transparent technical documentation.

What are the most likely causes and outcomes if this project fails?

The most likely failure modes are limited time, funding, and hardware capacity; difficulty recruiting the right

collaborators; and the possibility that the architecture proves too complex or insufficiently useful for external

developers to adopt.

A second risk is that testing may reveal gaps in the proposed safety boundaries. This would be treated as an

expected research outcome, not hidden or worked around: the affected capability would remain disabled or be removed

until it can be supported by clear evidence and tests.

If the project does not reach its intended scale, the outcome would be a smaller but still useful open-source

reference implementation, test suite, and documentation rather than a deployed autonomous system. aioa is

deliberately designed so that failure does not create uncontrolled execution risk: provider output, scores, and

proposals remain non-authoritative, while consequential actions stay behind explicit human approval and fail-closed

gates.

How much money have you raised in the last 12 months, and from where?

We have raised €0 in grant or external funding during the last 12 months.

The project has so far been developed independently, without institutional backing or external investment. We have

submitted AIOA NiFe spArk HAT to NLnet; the project has been accepted into their review process, and we are

currently awaiting a final funding decision. No funds have been awarded or received from NLnet at this stage.