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 2 hours ago
We opened FLUX 3 Action's code expecting our own pipeline. It closes 1.5 of 5 floors.
Black Forest Labs' FLUX 3 Action is a "world action model" for the SO-101 robot arm: one diffusion process jointly denoises the next chunk of actions and the next chunk of video frames. Read as a headline, that sounded like exactly the causal-chain-first architecture our own safety pipeline argues for — action and outcome tied together in one step, not an action head bolted onto a frozen representation. So we rented an L40S on Brev and read the code, not just the model card.
Our pipeline is five floors, each depending on the one below it: Causal chain → Probability → Risk/Impact → Decision theory → Markov/Game theory. Here's what FLUX 3 Action actually has.
01
Causal chain
Present, and prioritized: video_loss_weight: 1.0 outweighs action_loss_weight: 0.5. The model is trained to get the outcome right more than the action itself — this is the real thing, not a gesture at it.
present
02
Probability
Technically present, never surfaced. It's a diffusion model — it samples from a distribution by construction. Nothing reads that distribution back out as an uncertainty number a decision could use. The probability exists inside the math and dies there.
hollow
03
Risk / impact
Absent. The model card says so itself: "nothing bounds joint velocity, force, workspace." Not hidden — just not built.
absent
04
Decision theory
Absent. No gate. The model executes 32 actions per chunk; there is no threshold at which it would stop.
absent
05
Markov / game theory
Not applicable at this scope — a single robot arm with no adversary or multi-round state.
n/a
The closure isn't "their floors 1–2 are weaker than ours." They're not — floor 1 here is arguably cleaner than most causal-chain implementations we've seen, because the loss weighting makes the priority explicit in the training objective itself, not just in a README.
A model with two good, real, working floors behaves identically to a model posted an update about 2 hours ago
We opened FLUX 3 Action's code expecting our own pipeline. It closes 1.5 of 5 floors.
Black Forest Labs' FLUX 3 Action is a "world action model" for the SO-101 robot arm: one diffusion process jointly denoises the next chunk of actions and the next chunk of video frames. Read as a headline, that sounded like exactly the causal-chain-first architecture our own safety pipeline argues for — action and outcome tied together in one step, not an action head bolted onto a frozen representation. So we rented an L40S on Brev and read the code, not just the model card.
Our pipeline is five floors, each depending on the one below it: Causal chain → Probability → Risk/Impact → Decision theory → Markov/Game theory. Here's what FLUX 3 Action actually has.
01
Causal chain
Present, and prioritized: video_loss_weight: 1.0 outweighs action_loss_weight: 0.5. The model is trained to get the outcome right more than the action itself — this is the real thing, not a gesture at it.
present
02
Probability
Technically present, never surfaced. It's a diffusion model — it samples from a distribution by construction. Nothing reads that distribution back out as an uncertainty number a decision could use. The probability exists inside the math and dies there.
hollow
03
Risk / impact
Absent. The model card says so itself: "nothing bounds joint velocity, force, workspace." Not hidden — just not built.
absent
04
Decision theory
Absent. No gate. The model executes 32 actions per chunk; there is no threshold at which it would stop.
absent
05
Markov / game theory
Not applicable at this scope — a single robot arm with no adversary or multi-round state.
n/a
The closure isn't "their floors 1–2 are weaker than ours." They're not — floor 1 here is arguably cleaner than most causal-chain implementations we've seen, because the loss weighting makes the priority explicit in the training objective itself, not just in a README.
A model with two good, real, working floors behaves identically to a model repliedto their post 3 days 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
SoulInPsyAbstract/hermes3-8b-sequential-chain-lora
#12404 opened 13 days ago
by SoulInPsyAbstract