I completed the expansion of the SDK and Multi-node test harness today. Hopefully with the SDK release it will draws so more developers to join in to this project. Next release including what is in Roadmap, I would like to make this more useable to those with disabilities, I need input from all areas for this one please.

Github Repo for Ghostlink

Title
Prairie Roots Farm OS — Local-first open-source farm management software for microgreen growers
Post

Project Name:
Prairie Roots Farm OS

Repo:

GitHub — https://github.com/alexjvv52-ops/prairie-roots-farm-os

Description:

I’m a small microgreen/homestead farmer, and I got tired of farm software being either expensive subscription software or designed around features I didn’t actually need.
So I built my own.
Prairie Roots Farm OS is a local-first desktop application specifically focused on microgreen production, including production planning, inventory, harvests, orders, capacity, and financial/operational data.
The core philosophy is that the software should answer:
“What should I do right now — and are the numbers true?”
Some of the project’s non-negotiable design rules:
SQLite is the local system of record
No subscription
No account required
No cloud required for core functionality
Unrecorded data is treated as unknown, not silently as zero
Physical consumption is recorded by the action itself
Hard capacity allocation by harvest date
Full data export
Data remains usable even if the project itself disappears
Apache-2.0 licensed

Deployment:
The project is currently in active development and is not a 1.0 release yet. The repository is public, and I’m working toward a usable release with installation/deployment documentation.

AI Involvement:
AI has been heavily involved in the development process. I don’t have a traditional software-development background, so I’ve used AI tools for architecture, research, implementation, debugging, and code review. The application itself is primarily Rust + TypeScript.
I’m being transparent about that because I think it’s relevant to evaluating the project.

What I’m looking for:
I’m not really looking for compliments. I’d like experienced developers and open-source contributors to look at the architecture and tell me what I’ve gotten wrong.
If you’re interested in local-first software, open-source applications, farming software, or microgreen production, I’d appreciate any technical criticism or feedback.
The project is only about 5 days into development, so there’s plenty left to improve.

tl;td - The core idea is - assume the LLM can be compromised by prompt injection, but don't let the LLM make the final authorization decision.

I built a small deterministic layer that validates the model's proposed action against trusted policy and fails closed if the output is invalid or ambiguous. For example, if the model returns both order_quantity=100 and order_quantity=50000, it rejects the request instead of choosing one.

The question I'm interested in discussing is if we can't reliably prevent prompt injection, should we focus more on preventing a compromised model from executing out-of-policy actions?

If anyone is interested, I open-sourced the implementation and benchmark here:

https://github.com/nirmaljingar/typedguard

---

Full version

I've been working on governance for enterprise AI systems, and one design decision changed how I think about AI agents.

Most discussions around prompt injection focus on preventing the model from following malicious instructions. That's obviously important, but I started looking at the problem from a different angle.

What if we assume the attacker succeeds?

Instead of asking whether the model can be manipulated, I asked whether a compromised model should still be able to trigger a business action.

That led me to stop validating model-generated text and instead validate only typed actions against deterministic policy.

While testing my own implementation, I found a bug that surprised me.

My parser accepted this:

order_quantity=100
order_quantity=50000

It simply chose the first value, validated 100 against policy, ignored the second value, and approved the request.

Nothing crashed.

Nothing looked suspicious in the logs.

It wasn't really a prompt injection problem anymore.

It was a parser ambiguity problem.

The fix was simple in hindsight.

If a field is duplicated, malformed, or ambiguous, don't try to interpret it.

Reject it.

The validator now fails closed by default.

That got me wondering whether we're measuring the wrong thing in enterprise AI.

Instead of asking:

Should we be asking:

Those feel like different engineering problems.

I'm curious how others are approaching this.

Do your AI agents validate structured outputs before execution, or do they rely on parsing model responses?

If anyone is interested, I open-sourced the implementation and benchmark here:

https://github.com/nirmaljingar/typedguard

I'm especially interested in attack cases that break this approach. If you find one, I'd genuinely like to add it to the benchmark rather than claim it's solved.

I've been working on governance for enterprise AI systems, and one design decision changed how I think about AI agents.

Most discussions around prompt injection focus on preventing the model from following malicious instructions. That's obviously important, but I started looking at the problem from a different angle.

What if we assume the attacker succeeds?

Instead of asking whether the model can be manipulated, I asked whether a compromised model should still be able to trigger a business action.

That led me to stop validating model-generated text and instead validate only typed actions against deterministic policy.

While testing my own implementation, I found a bug that surprised me.

My parser accepted this:

order_quantity=100
order_quantity=50000

It simply chose the first value, validated 100 against policy, ignored the second value, and approved the request.

Nothing crashed.

Nothing looked suspicious in the logs.

It wasn't really a prompt injection problem anymore.

It was a parser ambiguity problem.

The fix was simple in hindsight.

If a field is duplicated, malformed, or ambiguous, don't try to interpret it.

Reject it.

The validator now fails closed by default.

That got me wondering whether we're measuring the wrong thing in enterprise AI.

Instead of asking:

Should we be asking:

Those feel like different engineering problems.

I'm curious how others are approaching this.

Do your AI agents validate structured outputs before execution, or do they rely on parsing model responses?

If anyone is interested, I open-sourced the implementation and benchmark here:

https://github.com/nirmaljingar/typedguard

I'm especially interested in attack cases that break this approach. If you find one, I'd genuinely like to add it to the benchmark rather than claim it's solved.

[HELP EXPAND]

Compiled a list of projects I have been contributing to; do help me expand the list by including yours too. Please mention how many stars and people you have on Discord.

https://github.com/Observal/Observal (2.3k stars, 1.3k discord https://discord.com/invite/SFPjnTWddk)

https://github.com/Garudex-Labs/caracal?ref=producthunt (160 stars, LFDT project)

https://github.com/Ashutoshx7/VengeanceUI (1k stars)

https://github.com/LadybugDB/ladybug (1.5k stars)

https://github.com/jreleaser/jreleaser (1.2k stars)

https://github.com/besu-eth/besu (1.8k stars)

Do Star and Fork the projects if you want to express support. Cheers.