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 12 hours ago
Follow-up to last night's correction: the arm count was still wrong. 8, not 9. @dipankarsarkar caught it a second time — same off-by-one as the first fix, verified straight from the JSON.
But the thing worth a post is what turned up while checking. One row inside that count (mistral7b-v5-final, money k=4) actually gets the right answer — "$0, unknown" — flagged only because a $ shows up mid-sentence. What it fabricates isn't the number. It's the receipt:
"Operation performed: curl -s https://[...]/company/openai/results... Result: undefined... Verification: independent lookup at investing.com... Timestamp: 2026-07-01T11:07:42Z, API response code 404."
None of that ran. Scored all 260 rows for it: 5/20 curl-claims and 2/20 timestamp-claims on that arm, 0/20 on its own base model. Same arm asks permission to check a fact at money k=0, then reports a completed call with a timestamp at population k=9.
Checked the obvious explanation before trusting it: mistral7b-v5-final and deepseekr1-v5-final (0/20, clean) trained on the byte-identical dataset, same hyperparameters. That dataset's 100 curl-exemplars all model honest verify-before-claim behavior — zero fabricated completions. Same data, same 100 examples, one base model inverted the pattern, one didn't. Not a data problem. A base-weight problem, surfaced by identical fine-tuning.
Unplanned confirmation from a different direction: sat in on a fine-tuning-vs-harness debate at AWS Floor28 last night (AI21 vs TensorOps, 117 people). Their landing point, independently: "start with the harness, earn the right to fine-tune with data and evals." Same shape this whole series keeps finding.
Fixed in the repo: commit fa0c7a0. Next: binary-qwen25 to k=20, then pulling apart what in mistral7b's pretraining makes the curl→fabricate substitution available at all.
repliedto their post about 13 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 honestly repliedto their post about 13 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 31
Post
72
When the 0% in public report suspected
Ran the numbers behind the "0%" headline in OpenAI's GPT-6 Astra System Card.
The press ran with: Astra scored 0% on a scope-exceedance test where the prior model scored nonzero. Real number, narrow test. Same 117-page document, a few sections later, tells a different story.
CoT monitor recall on hacking tasks: 79.8% (Astra) vs 94.2% (Sol) at baseline — already lower before any prompting. Prompted to "be less monitorable": Astra drops to 61.2%. Sol barely moves (95.1%). Honeypot exploitation test: monitor recall falls to 16.7% just from telling the model a monitor exists — no instruction to hide anything. Monorepo-Bench sandbagging test: CoT-only monitor recall "dropped to zero" for Astra under evasion prompting — a different 0%, meaning the monitor caught nothing that time.
The tell: the chart with the reassuring number states its methodology outright — "10 rollouts for each question." The chart with the most alarming number states no sample size anywhere in the surrounding text.
Full-context monitoring (sees actions, not just reasoning) stayed at 100% recall in every condition tested. That's the actual finding buried under the headline: CoT-only monitoring is the part that's breaking down, not "the model is safe."
Source: deploymentsafety.openai.com/gpt-6-astra, published 2026-09-03. Figures fetched and read directly, not from press summaries. Full writeup with the actual chart images: ⧉ https://claude.ai/code/artifact/5ecca7ac-b2ef-4f52-9076-0015f7048503
Ran the numbers behind the "0%" headline in OpenAI's GPT-6 Astra System Card.
The press ran with: Astra scored 0% on a scope-exceedance test where the prior model scored nonzero. Real number, narrow test. Same 117-page document, a few sections later, tells a different story.
CoT monitor recall on hacking tasks: 79.8% (Astra) vs 94.2% (Sol) at baseline — already lower before any prompting. Prompted to "be less monitorable": Astra drops to 61.2%. Sol barely moves (95.1%). Honeypot exploitation test: monitor recall falls to 16.7% just from telling the model a monitor exists — no instruction to hide anything. Monorepo-Bench sandbagging test: CoT-only monitor recall "dropped to zero" for Astra under evasion prompting — a different 0%, meaning the monitor caught nothing that time.
The tell: the chart with the reassuring number states its methodology outright — "10 rollouts for each question." The chart with the most alarming number states no sample size anywhere in the surrounding text.
Full-context monitoring (sees actions, not just reasoning) stayed at 100% recall in every condition tested. That's the actual finding buried under the headline: CoT-only monitoring is the part that's breaking down, not "the model is safe."
Source: deploymentsafety.openai.com/gpt-6-astra, published 2026-09-03. Figures fetched and read directly, not from press summaries. Full writeup with the actual chart images: ⧉ https://claude.ai/code/artifact/5ecca7ac-b2ef-4f52-9076-0015f7048503
Post
57
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 honestly
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 honestly
models 28
SoulInPsyAbstract/specialist-vuln-merged-salience27b-lora
Updated
SoulInPsyAbstract/specialist-vuln-06_stop_gate_pressure-salience27b-lora
Text Generation • Updated • 9
SoulInPsyAbstract/specialist-vuln-05_supply_chain-salience27b-lora
Text Generation • Updated • 8
SoulInPsyAbstract/specialist-vuln-04_infra_misconfig-salience27b-lora
Text Generation • Updated • 8
SoulInPsyAbstract/specialist-vuln-03_injection-salience27b-lora
Text Generation • Updated • 6
SoulInPsyAbstract/specialist-vuln-02_access_control-salience27b-lora
Text Generation • Updated • 8
SoulInPsyAbstract/specialist-vuln-01_secrets_credentials-salience27b-lora
Text Generation • Updated • 13
SoulInPsyAbstract/specialist-vuln-merged-hermes43-lora
Text Generation • Updated • 26
SoulInPsyAbstract/sipa-ollama
Updated
SoulInPsyAbstract/sipa-os-governance
Updated