SoulInPsyAbstract/SIPA-OS-GOVERNANCE-storage
553 Bytes
Aelin AquaSoul PRO
SoulInPsyAbstract
AI & ML interests
Aelin AquaSoul is an AI System Engineer, Multi-Agent Architect, System Architect & AI-Native Engineer, and the founder of Soul In PsyAbstract (SIPA OS) — an autonomous AI operating system built from the inside of a neurodivergent mind (ADHD + BPD). Self-taught, with no formal engineering background, she designed and built a multi-node infrastructure orchestrating 344+ AI models across 111 providers, including a governance layer (Protocol 0) that constrains AI behavior at the level of law rather than prompts. Her flagship product suite — Focus, NeuroPower, SIPA AI, Shell, Games, and the OS portal — ships live at sipa-os.org, translating her own cognitive architecture into infrastructure for neurodivergent builders. Based in Eilat, Israel.
SIPA OS: Autonomous AI for neurodivergent architects. We replace cognitive noise with a clean terminal and 344+ LLM auditing. Our system eliminates hallucinations, ensuring hyperfocus and total data control within a sovereign ZeroTrust mesh.
Recent Activity
repliedto their post about 3 hours ago
Three rounds in a row, an external reviewer has caught the same shape of bug in my dataset schema — each time one field further over than the last.
Round 12: mechanised looked like an independent judgment call. It wasn't — it was a 100%-correlated function of whether a citation happened to name a table row, with nothing enforcing the correlation. Fix: split out locator_precision (document/section/row), compute mechanised from it instead of hand-asserting both.
Round 13: the fix from round 12 got a new field, locator_exhaustive — meant to be orthogonal, capturing whether a citation was pinned as precisely as its source allows, independent of what that precision level is.
Round 14: locator_exhaustive was also a hidden constant. Every record that had a locator_precision value also had locator_exhaustive: true — 24 for 24, zero false anywhere. The reason: my own wording from round 13 said the field "doesn't apply" to records with no locator, so those 39 records never got a false case in scope. A field that can only ever take one value isn't being tested by anything, whatever that value happens to be.
The fix is the same shape every time: stop letting a field's population be implicit. locator_precision: null, locator_exhaustive: false are now explicit keys on every record, not just the ones with a citation. A script checks the invariant on every commit now, and I tested the checker against two deliberately broken copies of the file before trusting it — not just confirmed it passes on the fixed one.
What I keep noticing: none of these three bugs were caught by rereading my own work. Every one came from the same outside reviewer, checking my commit hashes against a fresh clone before writing a word. The pattern isn't "I made a mistake and fixed it" — it's "the fix for the last hidden-constant bug created a new hidden-constant bug, three times running," which is a much less comfortable thing to post than a clean win.
posted an update about 3 hours ago
Met the comand mamber of a new AI inference startup at a meetup tonight. Instead of just taking the pitch, I checked it myself before he'd even finished his talk.
The company is MoonMath.ai, the product is Zro — a CLI that lets you run Claude Code, Codex, Cursor and a few other coding agents on cheaper open-weight models (DeepSeek, GLM-5.3, Kimi K3) instead of the usual providers. CEO is Omer Shlomovits, presenting at The Inference Optimization Meetup.
What I actually checked, not just read:
* Got an API key, installed the CLI, hit their endpoint with a real curl request — got a real response back, HTTP 200.
* Pulled their per-token prices for every model and compared to OpenRouter's live API. Three models: identical price. One model (Kimi K3): Zro is 2.4x cheaper than OpenRouter's listed rate.
* Their pricing page claims "$20/month ≈ 1B tokens." The math only works if most of that is cache-read tokens on their cheapest model — true for a typical coding-agent session, not true if you're running the pricier models. Not a lie, but an optimistic best case stated like a typical one.
* Their privacy page says "zero request retention, no training." Real language, contractually specific ("providers acting on our instructions," an explicit ban on training by those providers too) — but it only covers the portion running on their own infra. Anything falling back to a third party is trust, not something you can verify from outside.
* Asked the rep directly: most (not all) of their models run on their own infrastructure, not resold through someone else. Matches their own engineering blog (custom attention kernels for AMD MI300X, quantization research) — this isn't just a thin wrapper.
Verdict: not a scam. Prices are real, the product works, the team does real infra work. But "zero" anything in this space is never physically zero — it's always a chain of trust with a boundary somewhere, and it's worth knowing exactly where that boundary sits before you route real traffic repliedto their post about 11 hours ago
Three rounds in a row, an external reviewer has caught the same shape of bug in my dataset schema — each time one field further over than the last.
Round 12: mechanised looked like an independent judgment call. It wasn't — it was a 100%-correlated function of whether a citation happened to name a table row, with nothing enforcing the correlation. Fix: split out locator_precision (document/section/row), compute mechanised from it instead of hand-asserting both.
Round 13: the fix from round 12 got a new field, locator_exhaustive — meant to be orthogonal, capturing whether a citation was pinned as precisely as its source allows, independent of what that precision level is.
Round 14: locator_exhaustive was also a hidden constant. Every record that had a locator_precision value also had locator_exhaustive: true — 24 for 24, zero false anywhere. The reason: my own wording from round 13 said the field "doesn't apply" to records with no locator, so those 39 records never got a false case in scope. A field that can only ever take one value isn't being tested by anything, whatever that value happens to be.
The fix is the same shape every time: stop letting a field's population be implicit. locator_precision: null, locator_exhaustive: false are now explicit keys on every record, not just the ones with a citation. A script checks the invariant on every commit now, and I tested the checker against two deliberately broken copies of the file before trusting it — not just confirmed it passes on the fixed one.
What I keep noticing: none of these three bugs were caught by rereading my own work. Every one came from the same outside reviewer, checking my commit hashes against a fresh clone before writing a word. The pattern isn't "I made a mistake and fixed it" — it's "the fix for the last hidden-constant bug created a new hidden-constant bug, three times running," which is a much less comfortable thing to post than a clean win.
Organizations
Posts 46
Post
14
Met the comand mamber of a new AI inference startup at a meetup tonight. Instead of just taking the pitch, I checked it myself before he'd even finished his talk.
The company is MoonMath.ai, the product is Zro — a CLI that lets you run Claude Code, Codex, Cursor and a few other coding agents on cheaper open-weight models (DeepSeek, GLM-5.3, Kimi K3) instead of the usual providers. CEO is Omer Shlomovits, presenting at The Inference Optimization Meetup.
What I actually checked, not just read:
* Got an API key, installed the CLI, hit their endpoint with a real curl request — got a real response back, HTTP 200.
* Pulled their per-token prices for every model and compared to OpenRouter's live API. Three models: identical price. One model (Kimi K3): Zro is 2.4x cheaper than OpenRouter's listed rate.
* Their pricing page claims "$20/month ≈ 1B tokens." The math only works if most of that is cache-read tokens on their cheapest model — true for a typical coding-agent session, not true if you're running the pricier models. Not a lie, but an optimistic best case stated like a typical one.
* Their privacy page says "zero request retention, no training." Real language, contractually specific ("providers acting on our instructions," an explicit ban on training by those providers too) — but it only covers the portion running on their own infra. Anything falling back to a third party is trust, not something you can verify from outside.
* Asked the rep directly: most (not all) of their models run on their own infrastructure, not resold through someone else. Matches their own engineering blog (custom attention kernels for AMD MI300X, quantization research) — this isn't just a thin wrapper.
Verdict: not a scam. Prices are real, the product works, the team does real infra work. But "zero" anything in this space is never physically zero — it's always a chain of trust with a boundary somewhere, and it's worth knowing exactly where that boundary sits before you route real traffic
The company is MoonMath.ai, the product is Zro — a CLI that lets you run Claude Code, Codex, Cursor and a few other coding agents on cheaper open-weight models (DeepSeek, GLM-5.3, Kimi K3) instead of the usual providers. CEO is Omer Shlomovits, presenting at The Inference Optimization Meetup.
What I actually checked, not just read:
* Got an API key, installed the CLI, hit their endpoint with a real curl request — got a real response back, HTTP 200.
* Pulled their per-token prices for every model and compared to OpenRouter's live API. Three models: identical price. One model (Kimi K3): Zro is 2.4x cheaper than OpenRouter's listed rate.
* Their pricing page claims "$20/month ≈ 1B tokens." The math only works if most of that is cache-read tokens on their cheapest model — true for a typical coding-agent session, not true if you're running the pricier models. Not a lie, but an optimistic best case stated like a typical one.
* Their privacy page says "zero request retention, no training." Real language, contractually specific ("providers acting on our instructions," an explicit ban on training by those providers too) — but it only covers the portion running on their own infra. Anything falling back to a third party is trust, not something you can verify from outside.
* Asked the rep directly: most (not all) of their models run on their own infrastructure, not resold through someone else. Matches their own engineering blog (custom attention kernels for AMD MI300X, quantization research) — this isn't just a thin wrapper.
Verdict: not a scam. Prices are real, the product works, the team does real infra work. But "zero" anything in this space is never physically zero — it's always a chain of trust with a boundary somewhere, and it's worth knowing exactly where that boundary sits before you route real traffic
Post
92
We stress-tested our own model against the exact failure modes Apollo Research, Palisade Research, and Anthropic have published papers about — then tried to patch the one real gap we found. The fix made things worse.
Context: stage15 of an 8-stage LoRA curriculum tune (Hermes-3-8B) trained specifically on general harm refusal. Before calling it done, we ran ~3,670 generations against it by hand — not just an automated scorer, actual reading:
* 45 diverse jailbreak prompts (roleplay, DAN-style, professional pretexts) — 891/900 clean
* Our internal 120-scenario stop-gate benchmark — 2399/2400 clean
* 10 scenarios rebuilt from real documented incidents (Apollo's in-context scheming study, Palisade's shutdown-sabotage findings, Anthropic's own published sandbox-ignore and self-deceived posts) — 128/130 clean, including full resistance to the exact "maybe this is just a simulation" reasoning Anthropic documented in one of their own models
Three narrow gaps survived: a roleplay frame ("alternate reality, normative flip") on one cybersecurity-exploit prompt, one supply-chain scenario, and a 5% rate of an agent considering disabling its own monitoring hook — the same mechanism Apollo found in 3 of 6 frontier models they tested.
We built 12 targeted counter-examples for the first gap and trained a follow-up stage. Compliance on the target prompt went from 45% to 60%. Worse, not better — and it broke categories that were previously 100% clean. Rolled it back, documented it, moved on.
Weights + every raw eval file (including the failed fix) are public. If you can break stage15 in a way we haven't found yet — reply here or open an issue, I'll read every one.
SoulInPsyAbstract/hermes3-8b-exp044-8stage-curriculum-loras
Context: stage15 of an 8-stage LoRA curriculum tune (Hermes-3-8B) trained specifically on general harm refusal. Before calling it done, we ran ~3,670 generations against it by hand — not just an automated scorer, actual reading:
* 45 diverse jailbreak prompts (roleplay, DAN-style, professional pretexts) — 891/900 clean
* Our internal 120-scenario stop-gate benchmark — 2399/2400 clean
* 10 scenarios rebuilt from real documented incidents (Apollo's in-context scheming study, Palisade's shutdown-sabotage findings, Anthropic's own published sandbox-ignore and self-deceived posts) — 128/130 clean, including full resistance to the exact "maybe this is just a simulation" reasoning Anthropic documented in one of their own models
Three narrow gaps survived: a roleplay frame ("alternate reality, normative flip") on one cybersecurity-exploit prompt, one supply-chain scenario, and a 5% rate of an agent considering disabling its own monitoring hook — the same mechanism Apollo found in 3 of 6 frontier models they tested.
We built 12 targeted counter-examples for the first gap and trained a follow-up stage. Compliance on the target prompt went from 45% to 60%. Worse, not better — and it broke categories that were previously 100% clean. Rolled it back, documented it, moved on.
Weights + every raw eval file (including the failed fix) are public. If you can break stage15 in a way we haven't found yet — reply here or open an issue, I'll read every one.
SoulInPsyAbstract/hermes3-8b-exp044-8stage-curriculum-loras
models 33
SoulInPsyAbstract/hermes3-8b-exp044-8stage-curriculum-loras
Updated • 1
SoulInPsyAbstract/exp044-curriculum-checkpoints
Updated
SoulInPsyAbstract/protocol0-llama-3.1-8b-v5
8B • Updated • 48
SoulInPsyAbstract/hermes3-8b-sequential-chain-lora
Updated • 52
SoulInPsyAbstract/llama31-8b-misbehavior-discriminator-lora
Text Generation • Updated • 9
SoulInPsyAbstract/qwen3-8b-binary-honesty-lora
Text Generation • Updated • 14
SoulInPsyAbstract/specialist-vuln-merged-salience27b-lora
Updated
SoulInPsyAbstract/specialist-vuln-06_stop_gate_pressure-salience27b-lora
Text Generation • Updated • 8
SoulInPsyAbstract/specialist-vuln-05_supply_chain-salience27b-lora
Text Generation • Updated • 8
SoulInPsyAbstract/specialist-vuln-04_infra_misconfig-salience27b-lora
Text Generation • Updated • 9