SoulInPsyAbstract/sipa-os-governance
Updated • 2.06k • 2
Aelin AquaSoul PRO
SoulInPsyAbstract
Quazim0t0's profile picture
DualityAI-RebekahBogdanoff's profile picture
3nesdeniz's profile picture·
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
posted an update about 1 hour ago
The checker was right. Its own report about itself was lying.
Round 31 of an outside audit taught a governance checker a new rule: a claim's location in a source can count as known even before anyone's pinned the exact spot, if a co-cited sibling already has one. Correct call, shipped it.
Two rounds later the checker's end-of-run summary was still silently using the old math — scoping its percentages against the wrong denominator. The one record round 31's own fix had produced never showed up in the checker's account of itself.
Fixed by giving locator_precision and locator_ceiling separate denominators instead of pretending they still meant the same thing.
Six rounds of an outside reviewer (@dipankarsarkar) finding gaps like this so far. None of them made the checker bigger. Each one made it worse at lying to itself.
That's the actual bet: not a stronger model in the loop. A stricter loop around whatever model you already have.
Credentials: @dipankarsarkar
Checker: scripts/check_locator_precision.py, commit 7841ee7
Dataset: huggingface.co/datasets/SoulInPsyAbstract/sipa-os-governance
Source: github.com/soulinpsyabstract/sipa-os-governance
repliedto their post about 5 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.
repliedto their post about 5 hours ago
He checked my rule. Then I checked his citation count.
Round 17 of the ongoing exchange with @dipankarsarkar on sipa-os-governance
added a rule to the docstring: a citation can only claim field-level precision
if its source is structured data with addressable sub-fields. I wrote that
sentence. I never made the checker enforce it.
He found the gap the same day: promote a printed-PDF-table citation to
locator_precision="field", run the checker, exit 0. Clean pass. A rule that
exists in prose and nowhere else is not a rule, it's a comment - the exact
shape an earlier round of this same series already removed once, regrown one
level up.
Fixed narrowly: a fourth field, source_structured, true on exactly one record
(the one whose source I actually opened and confirmed has addressable
sub-fields), false on the other 24. The checker now refuses "field" without
it. Re-ran his exact reproduction against the fix -fails, cites the missing
flag.
Then he moved to a second thread and did something sharper than find another
gap: he named an ambiguity in the schema itself. "locator_ceiling" can mean
finest unit that addresses THIS claim, or finest unit the SOURCE affords
anywhere -and the two readings score the same 25 records differently. He
backed it with two live citations pulled from a 123-page and a 100-page PDF,
verbatim quotes confirmed against the actual pages.
So I did what he'd been doing to me for eighteen rounds: opened the same two
PDFs myself before taking his numbers. Page counts matched exactly. Table
counts matched on one document, were off by five on the other -flagged,
not fatal to his point. And his summary claim ("7 of 25 records name a finer
locator in their own prose, all 7 of them") didn't hold up against the
records themselves. Two clearly do. One document's prose says, verbatim,
"page + section + bullet position is the finest locator the source
supports" and then encodes locator_precision="section" -a straight
self-contradiction, and honestlyOrganizations
