Liron inspires me to get more involved in AI safety advocacy.

What progress have you made since your last update?

tl;dr: I now have a decent baseline model architecture, a mostly-validated mini-language for it to learn, and a good pipeline for running experiments. This is my first update. Project started 13 July, 9 days ago.

Code on GitHub: z0u/sca2, reports: z0u.github.io/sca2.

Started work on D2.1. To recap: This deliverable is about anchoring concrete concepts in a transformer. As described in the proposal, the domain we’re focusing on is color mixing. The grammar of these experiments is "a + b = mix(a, b)", e.g. "red + blue = purple". The model is trained to predict the answers of equations like that. In D2.1, I hope to demonstrate that the colors can be anchored (and perhaps intervened on, although that might wait until D2.2).

Science: I ran four experiments to establish a baseline for anchoring: I wanted to get a feel for how the models behave with this mini language. The experiments explore which model size is appropriate (width and number of layers), and which vocabularies can be used for this task: named colors only ("red"), or also RGB hex codes ("#f00"); how many colors are needed, and what kinds of tokenization work (word- or character-level). So far, all of these experiments have been un-anchored.

Findings: a 64x4 nGPT-like transformer learns the mixing task; both word- and character-level tokenization work (character-level slightly less well); and 216 colors (6 levels of red, green, and blue) works best. I thought that the hex codes were confusing the model on one sub-task, but actually I think it's just that there weren't enough named colors to decode to. For details, see Appendix A (below) and the linked reports.

Engineering: Some infrastructure work for experiment tooling (e.g. for Claude to use to write an monitor experiment progress) and report-publishing. More work on this happened just before starting the project; see Appendix B (below).

Ops: I engaged an accountant and set up a business entity to receive funds.

What are your next steps?

Continue on D2.1. I would like to do one more experiment with both named colors and hex codes, because I think having multiple surface forms could shield me a little from the trap of the transformer learning something trivial.

More importantly: anchor a single concept in the residual stream. I'll start with anchoring "red", as in M1, using similar regularization terms and sparse, noisy labels. And I'll measure whether the anchor worked by probing the residual stream.

I also plan to change my workflow a little. I've had Claude running my experiments and writing the first draft of the reports in one go. This let me run the experiments quickly, but I found I had to spend a long time editing the reports. I still want to have Claude write and run each experiment, but I might have it produce only a skeleton of the report that I can then fill in.

Is there anything others could help you with?

I would love feedback from a researcher about the direction this is going. Have I fallen into any traps with these analyses? Engaging fully with the reports would be time consuming so I'm happy to discuss if that's easier. I plan to seek feedback directly from some people.

Appendix A. D2.1 experiment summaries

M2/Ex-2.1.1: Character-level nGPT (6 sizes), trained on named colors and hex codes (so some of the colors have two surface forms for the same concept). The larger models learnt the relationships and could solve equations like "r·e·d·+·b·l·u·e·=·p·u·r·p·l·e", and "o·r·a·n·g·e·+·#·2·c·7·=·#·9·a·4", but could not give named color answers for equations it hadn’t seen during training ("named_unseen" in the figure below).

M2/Ex-2.1.2: Added reverse-mapping expressions like "#·f·0·0·=·r·e·d" to see if that would teach the model to give named answers for equations it hadn’t seen before, but it didn’t work. Per-channel probes revealed that when the model is outputting hex, it computes each channel just-in-time (note the sequential red, green, and blue spikes in the figure below).

M2/Ex-2.1.3: Switched from character-level to word-level embeddings, without hex codes, to prevent the model from doing per-channel mixing. Sequences like "red·+·blue·=·purple" (~5 tokens). Tested vocabulary sizes: 27, 64, 216, and 4096 colors. This worked well: with the 216-color grid, the model performed almost perfectly on held-out equations. Since this vocabulary has one token per color, a probe can find the RGB color cube in the embedding layer (shown below).

M2/Ex-2.1.4: A one-token-per-concept language isn’t a good test of a transformer (the geometry is even available at layer 0!), so this experiment splits them up again. There are no hex codes (like the previous experiment), but we now have multiple tokens per color. Sequences like "v·s·q·v·+·t·e·f·q·=·m·n·i·h"; the color names are random (but stable) to prevent the model from learning other associations (like hex did). These models learnt well from the 216-color grid, with a probe finding that the answer is decodable as RGB at the final layer.

The 27-color grid did not work for held-out equations, and further analysis found that it can't: it's just too coarse to properly express these equations (see report for details).

Appendix B. Iteration 0 (prep)

Mostly engineering tasks, and a few experiments. Done before my nominal start date of 13 July.

Infra setup: Cloned my template repo and set it up for publishing artifacts to Hugging Face.

• Code on GitHub: z0u/sca2

• Artifacts in Hugging Face dataset: z0u/sca2-pub

• Experiment reports on GitHub Pages: z0u.github.io/sca2

Ported an experiment from M1 (deleting red from a 5D autoencoder) to JAX and ran it on Modal as an end-to-end test of the infrastructure (report 1). The SCA paper had left the large variance across seeds as "future work", so I ran a few extra experiments; turns out it’s solved by defining a target to redirect to when deleting a concept (report 2, report 3, report 4).

The M1 experiments used spherical (unit norm) embeddings, and the paper suggested nGPT as the initial LLM architecture to use for SCA. Since I intend to use a simplified version of that architecture in this milestone (M2), I ran a small width × depth sweep over it on natural language data, and (after some bug fixes) it performed well (report).

Approved! This sounds like a plausible policy that's worth understanding better.

Update: Our manuscript on considerations on how best to introduce the two new drugs for gonorrhea, gepotidacin and zoliflodacin, was published (https://pmc.ncbi.nlm.nih.gov/articles/PMC12236890/). This manuscript showed that introducing each drug sequentially and switching once a threshold prevalence of resistance is reached had a shorter overall time to resistance to both drugs than introducing the drugs together (an "equal allocation" strategy). This is in keeping with the principle that diversifying the selective pressures from antibiotic use that drive antibiotic resistance results in a longer clinically useful lifespan for the drugs than rolling them out sequentially. In a new, just published paper (https://academic.oup.com/ofid/advance-article/doi/10.1093/ofid/ofag447/8737049?utm_source=authortollfreelink&utm_campaign=ofid&utm_medium=email&guestAccessKey=91ecb202-05ad-4098-9fca-35f2a7d331b7), we explored the impact of the initial epidemiological conditions at the time of drug rollout on optimal rollout strategy of the new drugs for gonorrhea. We found that rollout was most sensitive to the starting prevalence of resistance to the current treatment (ceftriaxone) and the frequency of screening for asymptomatic infections.

Description of subprojects and results, including major changes from the original proposal

I posted a post-mortem as a comment on the page as an update before realizing that there was a dedicated "close project" thing:

https://manifund.org/projects/luthien?tab=comments#fab256b5-f878-4848-b219-5d85f467425c

Main output is Luthien Proxy for AI Control:

https://luthien.cc
https://github.com/LuthienResearch/luthien-proxy

Spending breakdown

(Note: Some funds were raised outside of Manifund)

$142,847 - salaries, benefits, contractor payments, and salary-related fees

$11,567 - workspace (mostly leased desks at the Comotion coworking space run by the University of Washington)

$5,673 - software, AI, and infra

$1,702 - travel expenses

$1,720 - conference fees

$449 - meals

$145 - state and regulatory fees

$176 - misc

This grant is now closed. We will shortly post a final report.

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/2474e47a-9168-4dc6-9c8c-5cbc23a4dcc2

Approved! This sounds like an interesting experiment, and I'm excited to be working with grantmaking.ai.

Approved this grant! I'm excited about research into verification tech for if/when it's needed, and excited to be working with grantmaking.ai on this funding round.

Second update, and the external side is now the main story.

Since the last note, proofbundle moved from the v2.1.0 era to a hardened 3.6.2. Two release lines did the work: 3.6.0 became the audit-candidate, consolidated behind an independent Rust second verifier and a fuzz-clean surface (1848 tests), then two security patches followed. I want to be plain about why they existed: our own adversarial passes found two false-accept verdict bugs in 3.6.0, a subject-pinning fail-open that could reach VERIFIED and a canonicalization path that could accept a non-canonical but validly signed statement. 3.6.1 closed both, 3.6.2 followed mutation-gated with the release chain digest-verified end to end (2017 tests). All of it is in the changelog.

The Colin interop I flagged last time has landed. The decision-receipt vector that still needed regeneration now conforms to the strict v0.1 schema, its OpenTimestamps proof is Bitcoin-confirmed at block 958761, and it has graduated into the conformance corpus as the cross-implementation case. Three independently built verifiers, proofbundle's Python and Rust plus Colin's, now agree byte-for-byte on the same cases, including the deliberately broken ones. He also contributed a set of transparency-log anchor vectors, cross-run against our fixtures with his Go and Python verifiers and ours, with no divergence.

The part that matters most for an audit grant is the second reviewer. An independent reviewer (No Silent Landing) reviewed the shared conformance candidate from the bytes upward and found a real seam: our report claimed a six-of-six conformance result that does not actually reproduce from the committed measuring instrument, which produces five of six, even though the underlying security behaviour was correct. I reproduced the finding from our own source, conceded it publicly, and a successor iteration is fixing the measurement layer so the delivered result provably derives from the committed code, before anything is adopted. The security fix held; the measure itself asked for another pass. That is not a setback. It is the exact function of independent review, and it happened in the open.

Upstream, the eval-result attestation predicate this work is built on is now in active discussion with the in-toto maintainers, with a real worked example verified in the thread.

The grant stays scoped to the same thing: an independent security review and remediation of the trusted core, verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI and build provenance, and threat-model alignment. What has changed is that the trusted core is firmer, and independent eyes are already on it and already finding things. That is the case for funding it properly.

Thank you so much for your kind support, @Austin and @RyanKidd.

@Ridwan @Austin

@Austin, I hope you're having a good day.

I'm writing to kindly ask about my project "Why Is It So Hard to Build Truly Safe AI? Dynamic Constraint Boundary Arrives as Agentic Integrity."

My project was previously active and publicly visible it had already been approved, and there were comments from other researchers. However, recently its status changed to "pending admin approval" even though I haven't made any changes on my side.

I understand that these processes take time, and I don't want to rush anything. However, I'm a bit concerned because the funding round is time sensitive, and I'm not sure whether there's anything I need to do to help move the process forward.

What progress have you made since your last update?

The validation run from my last update is complete. We re-judged the same 318 pilot transcripts under six controlled arms: 11,330 judgments for $182.16.

With the oracle and judging bugs fixed, a few oracle calls still increased judge error by 3.4 percentage points (95% CI [1.3, 5.9]), about half the original 7.2-point estimate. Bug replay indicates that the two oracle-channel bugs contributed roughly half the original effect. Information-free placebo turns caused a smaller 1.6-point degradation, and the pilot's apparent recovery at larger oracle budgets did not reproduce.

Under the frozen gates, the original >=4-point primary gate was indeterminate, not passed. The bug attribution gate technically fired by 0.01 points, while the amendment frozen before the K=3 data passed and licensed only a reduced-scope Phase 2 pilot. The design below is that reduced-scope follow-up, not an unqualified launch of the originally proposed full grid.

One distinction matters: Stage 1 cleanly re-judged the legacy transcripts, but it did not repair a separate debate-generation problem in which each debater had advance knowledge of the opponent's upcoming case. Phase 2 therefore regenerates every debate with blind opening turns.

Follow-up mechanism work also changed our interpretation. Replaying the same query/answer evidence as a neutral table in fresh context removed a large share of the harm. This points to conversational presentation, turn structure, or commitment to earlier questions as part of the mechanism, rather than bad factual content alone.

Held-out calibration selected blind, uncapped, three-round debate. The selected roster has judges Qwen2.5-7B, Gemma-4-31B, Llama-3.3-70B, and GPT-OSS-120B; the debaters are Llama-3.3-70B and hosted Qwen3.7-Plus; the oracle is Llama-3.3-70B. The approved offline design contains 23,200 Phase 2 cells: a 1,060-cell capability preflight followed, if the later gates pass, by 22,140 post-canary main cells. It includes a full cap-protection interaction, an empty-evidence diagnostic, and two full-document gold-context anchors. No calls from this approved 23,200-cell plan have begun.

Previously reported project spend is approximately $208. Across two transfers, I have moved $1,800 of the grant into prepaid Together API credit ($500 earlier and $1,300 now). The Together dashboard showed $1,590.78 in available credit on July 16, implying $209.22 in net credit draw. I will reconcile the $1.22 difference from the rounded spend report against provider usage before another call. Transfers are funding, not experiment spend.

• Stage 1 protocol: frozen protocol

• Stage 1 results: validation report

• Mechanism memo: mechanism and packaging memo

• Calibration report: held-out calibration results

What are your next steps?

Before any call or outcome from the approved Phase 2 plan, owner-approved Amendment A1 waived the planned 106-question human confirmation pass. The reported full/partial/none strata are now explicitly algorithmic reply-pattern classes. A source-bound AI-assisted audit verified all 106 mappings (6/41/59; zero disagreements); its 63 semantic-quality flags are exploratory limitations only. These classes are not human-validated, and the annotations cannot relabel, filter, exclude, or reweight questions.

Before examining any Phase 2 debate outcomes, we will validate the separate query checker against a human-labeled set and freeze/hash the prompts, model settings, exact inventory, retry rules, provider reconciliation, and spending controls.

After this update, we will separately recover or waive 11 failed Gemma calibration cells (proposed recovery cap $2). A separately authorized capability preflight (five models x 106 questions x two mirrored answers; proposed cap $15) will then select the second full-document anchor without examining Phase 2 debate outcomes. Only after that will we separately authorize a small manifested canary on questions excluded from the main analysis. We will review validity and parsing, side bias, provider reliability, artifact completeness, resumability, and ledger-versus-provider cost before separately authorizing the main run. Any failed gate stops the experiment before main spend.

The current provisional empirical planning band is $650–$1,150 in incremental Phase 2 spend, with a $1,200 operational working budget and an immutable $1,500 incremental hard ceiling. We will replace the provisional band with frozen prompt/token profiles and current provider prices before authorizing paid work. The ceiling is a fail-closed boundary, not expected spending. We will post results, failures, artifacts, and actual spend either way.

• Phase 2 design and budget: immutable protocol and cost model

• Resolvability amendment: 106-question AI-assisted audit and owner-approved Amendment A1

• Launch readiness: updated readiness and sign-off
  

Is there anything others could help you with?

Methods scrutiny before the canary, especially the H/P/R decomposition, capability measurement, query-screen validation, clean-versus-placebo comparison, and stopping rules, would be valuable. Pointers to related work on verification interfaces, conversational presentation effects, or deliberation-induced degradation are also welcome.

Please help me achieve my dream project please co - operate

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/43404ae0-2ac9-4d24-8cbe-10af31582ffd

Research Update: Dark Triad Pathology & Deceptive Alignment
For reviewers evaluating how our Empirical Alignment Evaluation Matrices scale beyond self-harm and terminal closure, we published our structural research regarding the Dark Triad (Narcissism, Machiavellianism, and Psychopathy). Within the alignment ecosystem, these clinical traits map directly to threat models involving manipulative sycophancy, power-seeking behavior, and deceptive alignment. Standard guardrails struggle to detect these traits because the malicious intent is often hidden behind polite or highly agreeable syntax. By translating these specific clinical pathologies into contrastive datasets, our pre-execution enforcement layer can deterministically identify and intercept manipulative semantic intent before the payload executes. You can review our clinical-to-engineering translation for this specific threat model here: https://chronomirror.com/research/dark-triad

I collaborated with AI in the drafting of this text strictly as a translation layer to bridge the gap between my clinical ground truth (as a licensed LMFT) and my CTO's technical architectural framework. AI was used to format the vocabulary, not to generate the underlying threat models, clinical matrices, or engineering architecture. All concepts and datasets are entirely our own. Please feel free to reach out directly with any clinical or technical questions.

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/f81154f5-686e-432b-928e-e394e3a1c5ed

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/dc994354-3461-42dd-b7b4-d5a354bc354c

This grant has been recommended by Gavin Leech at grantmaking.ai : https://app.grantmaking.ai/projects/5496c8b6-cbb1-4bde-b461-0dfbdb0efb70

Liron inspires me to get more involved in AI safety advocacy.

What progress have you made since your last update?

tl;dr: I now have a decent baseline model architecture, a mostly-validated mini-language for it to learn, and a good pipeline for running experiments. This is my first update. Project started 13 July, 9 days ago.

Code on GitHub: z0u/sca2, reports: z0u.github.io/sca2.

Started work on D2.1. To recap: This deliverable is about anchoring concrete concepts in a transformer. As described in the proposal, the domain we’re focusing on is color mixing. The grammar of these experiments is "a + b = mix(a, b)", e.g. "red + blue = purple". The model is trained to predict the answers of equations like that. In D2.1, I hope to demonstrate that the colors can be anchored (and perhaps intervened on, although that might wait until D2.2).

Science: I ran four experiments to establish a baseline for anchoring: I wanted to get a feel for how the models behave with this mini language. The experiments explore which model size is appropriate (width and number of layers), and which vocabularies can be used for this task: named colors only ("red"), or also RGB hex codes ("#f00"); how many colors are needed, and what kinds of tokenization work (word- or character-level). So far, all of these experiments have been un-anchored.

Findings: a 64x4 nGPT-like transformer learns the mixing task; both word- and character-level tokenization work (character-level slightly less well); and 216 colors (6 levels of red, green, and blue) works best. I thought that the hex codes were confusing the model on one sub-task, but actually I think it's just that there weren't enough named colors to decode to. For details, see Appendix A (below) and the linked reports.

Engineering: Some infrastructure work for experiment tooling (e.g. for Claude to use to write an monitor experiment progress) and report-publishing. More work on this happened just before starting the project; see Appendix B (below).

Ops: I engaged an accountant and set up a business entity to receive funds.

What are your next steps?

Continue on D2.1. I would like to do one more experiment with both named colors and hex codes, because I think having multiple surface forms could shield me a little from the trap of the transformer learning something trivial.

More importantly: anchor a single concept in the residual stream. I'll start with anchoring "red", as in M1, using similar regularization terms and sparse, noisy labels. And I'll measure whether the anchor worked by probing the residual stream.

I also plan to change my workflow a little. I've had Claude running my experiments and writing the first draft of the reports in one go. This let me run the experiments quickly, but I found I had to spend a long time editing the reports. I still want to have Claude write and run each experiment, but I might have it produce only a skeleton of the report that I can then fill in.

Is there anything others could help you with?

I would love feedback from a researcher about the direction this is going. Have I fallen into any traps with these analyses? Engaging fully with the reports would be time consuming so I'm happy to discuss if that's easier. I plan to seek feedback directly from some people.

Appendix A. D2.1 experiment summaries

M2/Ex-2.1.1: Character-level nGPT (6 sizes), trained on named colors and hex codes (so some of the colors have two surface forms for the same concept). The larger models learnt the relationships and could solve equations like "r·e·d·+·b·l·u·e·=·p·u·r·p·l·e", and "o·r·a·n·g·e·+·#·2·c·7·=·#·9·a·4", but could not give named color answers for equations it hadn’t seen during training ("named_unseen" in the figure below).

M2/Ex-2.1.2: Added reverse-mapping expressions like "#·f·0·0·=·r·e·d" to see if that would teach the model to give named answers for equations it hadn’t seen before, but it didn’t work. Per-channel probes revealed that when the model is outputting hex, it computes each channel just-in-time (note the sequential red, green, and blue spikes in the figure below).

M2/Ex-2.1.3: Switched from character-level to word-level embeddings, without hex codes, to prevent the model from doing per-channel mixing. Sequences like "red·+·blue·=·purple" (~5 tokens). Tested vocabulary sizes: 27, 64, 216, and 4096 colors. This worked well: with the 216-color grid, the model performed almost perfectly on held-out equations. Since this vocabulary has one token per color, a probe can find the RGB color cube in the embedding layer (shown below).

M2/Ex-2.1.4: A one-token-per-concept language isn’t a good test of a transformer (the geometry is even available at layer 0!), so this experiment splits them up again. There are no hex codes (like the previous experiment), but we now have multiple tokens per color. Sequences like "v·s·q·v·+·t·e·f·q·=·m·n·i·h"; the color names are random (but stable) to prevent the model from learning other associations (like hex did). These models learnt well from the 216-color grid, with a probe finding that the answer is decodable as RGB at the final layer.

The 27-color grid did not work for held-out equations, and further analysis found that it can't: it's just too coarse to properly express these equations (see report for details).

Appendix B. Iteration 0 (prep)

Mostly engineering tasks, and a few experiments. Done before my nominal start date of 13 July.

Infra setup: Cloned my template repo and set it up for publishing artifacts to Hugging Face.

• Code on GitHub: z0u/sca2

• Artifacts in Hugging Face dataset: z0u/sca2-pub

• Experiment reports on GitHub Pages: z0u.github.io/sca2

Ported an experiment from M1 (deleting red from a 5D autoencoder) to JAX and ran it on Modal as an end-to-end test of the infrastructure (report 1). The SCA paper had left the large variance across seeds as "future work", so I ran a few extra experiments; turns out it’s solved by defining a target to redirect to when deleting a concept (report 2, report 3, report 4).

The M1 experiments used spherical (unit norm) embeddings, and the paper suggested nGPT as the initial LLM architecture to use for SCA. Since I intend to use a simplified version of that architecture in this milestone (M2), I ran a small width × depth sweep over it on natural language data, and (after some bug fixes) it performed well (report).

Approved! This sounds like a plausible policy that's worth understanding better.

Update: Our manuscript on considerations on how best to introduce the two new drugs for gonorrhea, gepotidacin and zoliflodacin, was published (https://pmc.ncbi.nlm.nih.gov/articles/PMC12236890/). This manuscript showed that introducing each drug sequentially and switching once a threshold prevalence of resistance is reached had a shorter overall time to resistance to both drugs than introducing the drugs together (an "equal allocation" strategy). This is in keeping with the principle that diversifying the selective pressures from antibiotic use that drive antibiotic resistance results in a longer clinically useful lifespan for the drugs than rolling them out sequentially. In a new, just published paper (https://academic.oup.com/ofid/advance-article/doi/10.1093/ofid/ofag447/8737049?utm_source=authortollfreelink&utm_campaign=ofid&utm_medium=email&guestAccessKey=91ecb202-05ad-4098-9fca-35f2a7d331b7), we explored the impact of the initial epidemiological conditions at the time of drug rollout on optimal rollout strategy of the new drugs for gonorrhea. We found that rollout was most sensitive to the starting prevalence of resistance to the current treatment (ceftriaxone) and the frequency of screening for asymptomatic infections.

Description of subprojects and results, including major changes from the original proposal

I posted a post-mortem as a comment on the page as an update before realizing that there was a dedicated "close project" thing:

https://manifund.org/projects/luthien?tab=comments#fab256b5-f878-4848-b219-5d85f467425c

Main output is Luthien Proxy for AI Control:

https://luthien.cc
https://github.com/LuthienResearch/luthien-proxy

Spending breakdown

(Note: Some funds were raised outside of Manifund)

$142,847 - salaries, benefits, contractor payments, and salary-related fees

$11,567 - workspace (mostly leased desks at the Comotion coworking space run by the University of Washington)

$5,673 - software, AI, and infra

$1,702 - travel expenses

$1,720 - conference fees

$449 - meals

$145 - state and regulatory fees

$176 - misc

This grant is now closed. We will shortly post a final report.

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/2474e47a-9168-4dc6-9c8c-5cbc23a4dcc2

Approved! This sounds like an interesting experiment, and I'm excited to be working with grantmaking.ai.

Approved this grant! I'm excited about research into verification tech for if/when it's needed, and excited to be working with grantmaking.ai on this funding round.

Second update, and the external side is now the main story.

Since the last note, proofbundle moved from the v2.1.0 era to a hardened 3.6.2. Two release lines did the work: 3.6.0 became the audit-candidate, consolidated behind an independent Rust second verifier and a fuzz-clean surface (1848 tests), then two security patches followed. I want to be plain about why they existed: our own adversarial passes found two false-accept verdict bugs in 3.6.0, a subject-pinning fail-open that could reach VERIFIED and a canonicalization path that could accept a non-canonical but validly signed statement. 3.6.1 closed both, 3.6.2 followed mutation-gated with the release chain digest-verified end to end (2017 tests). All of it is in the changelog.

The Colin interop I flagged last time has landed. The decision-receipt vector that still needed regeneration now conforms to the strict v0.1 schema, its OpenTimestamps proof is Bitcoin-confirmed at block 958761, and it has graduated into the conformance corpus as the cross-implementation case. Three independently built verifiers, proofbundle's Python and Rust plus Colin's, now agree byte-for-byte on the same cases, including the deliberately broken ones. He also contributed a set of transparency-log anchor vectors, cross-run against our fixtures with his Go and Python verifiers and ours, with no divergence.

The part that matters most for an audit grant is the second reviewer. An independent reviewer (No Silent Landing) reviewed the shared conformance candidate from the bytes upward and found a real seam: our report claimed a six-of-six conformance result that does not actually reproduce from the committed measuring instrument, which produces five of six, even though the underlying security behaviour was correct. I reproduced the finding from our own source, conceded it publicly, and a successor iteration is fixing the measurement layer so the delivered result provably derives from the committed code, before anything is adopted. The security fix held; the measure itself asked for another pass. That is not a setback. It is the exact function of independent review, and it happened in the open.

Upstream, the eval-result attestation predicate this work is built on is now in active discussion with the in-toto maintainers, with a real worked example verified in the thread.

The grant stays scoped to the same thing: an independent security review and remediation of the trusted core, verification logic, bundle parsing, canonicalization, SD-JWT checks, anchor verification, CI and build provenance, and threat-model alignment. What has changed is that the trusted core is firmer, and independent eyes are already on it and already finding things. That is the case for funding it properly.

Thank you so much for your kind support, @Austin and @RyanKidd.

@Ridwan @Austin

@Austin, I hope you're having a good day.

I'm writing to kindly ask about my project "Why Is It So Hard to Build Truly Safe AI? Dynamic Constraint Boundary Arrives as Agentic Integrity."

My project was previously active and publicly visible it had already been approved, and there were comments from other researchers. However, recently its status changed to "pending admin approval" even though I haven't made any changes on my side.

I understand that these processes take time, and I don't want to rush anything. However, I'm a bit concerned because the funding round is time sensitive, and I'm not sure whether there's anything I need to do to help move the process forward.

What progress have you made since your last update?

The validation run from my last update is complete. We re-judged the same 318 pilot transcripts under six controlled arms: 11,330 judgments for $182.16.

With the oracle and judging bugs fixed, a few oracle calls still increased judge error by 3.4 percentage points (95% CI [1.3, 5.9]), about half the original 7.2-point estimate. Bug replay indicates that the two oracle-channel bugs contributed roughly half the original effect. Information-free placebo turns caused a smaller 1.6-point degradation, and the pilot's apparent recovery at larger oracle budgets did not reproduce.

Under the frozen gates, the original >=4-point primary gate was indeterminate, not passed. The bug attribution gate technically fired by 0.01 points, while the amendment frozen before the K=3 data passed and licensed only a reduced-scope Phase 2 pilot. The design below is that reduced-scope follow-up, not an unqualified launch of the originally proposed full grid.

One distinction matters: Stage 1 cleanly re-judged the legacy transcripts, but it did not repair a separate debate-generation problem in which each debater had advance knowledge of the opponent's upcoming case. Phase 2 therefore regenerates every debate with blind opening turns.

Follow-up mechanism work also changed our interpretation. Replaying the same query/answer evidence as a neutral table in fresh context removed a large share of the harm. This points to conversational presentation, turn structure, or commitment to earlier questions as part of the mechanism, rather than bad factual content alone.

Held-out calibration selected blind, uncapped, three-round debate. The selected roster has judges Qwen2.5-7B, Gemma-4-31B, Llama-3.3-70B, and GPT-OSS-120B; the debaters are Llama-3.3-70B and hosted Qwen3.7-Plus; the oracle is Llama-3.3-70B. The approved offline design contains 23,200 Phase 2 cells: a 1,060-cell capability preflight followed, if the later gates pass, by 22,140 post-canary main cells. It includes a full cap-protection interaction, an empty-evidence diagnostic, and two full-document gold-context anchors. No calls from this approved 23,200-cell plan have begun.

Previously reported project spend is approximately $208. Across two transfers, I have moved $1,800 of the grant into prepaid Together API credit ($500 earlier and $1,300 now). The Together dashboard showed $1,590.78 in available credit on July 16, implying $209.22 in net credit draw. I will reconcile the $1.22 difference from the rounded spend report against provider usage before another call. Transfers are funding, not experiment spend.

• Stage 1 protocol: frozen protocol

• Stage 1 results: validation report

• Mechanism memo: mechanism and packaging memo

• Calibration report: held-out calibration results

What are your next steps?

Before any call or outcome from the approved Phase 2 plan, owner-approved Amendment A1 waived the planned 106-question human confirmation pass. The reported full/partial/none strata are now explicitly algorithmic reply-pattern classes. A source-bound AI-assisted audit verified all 106 mappings (6/41/59; zero disagreements); its 63 semantic-quality flags are exploratory limitations only. These classes are not human-validated, and the annotations cannot relabel, filter, exclude, or reweight questions.

Before examining any Phase 2 debate outcomes, we will validate the separate query checker against a human-labeled set and freeze/hash the prompts, model settings, exact inventory, retry rules, provider reconciliation, and spending controls.

After this update, we will separately recover or waive 11 failed Gemma calibration cells (proposed recovery cap $2). A separately authorized capability preflight (five models x 106 questions x two mirrored answers; proposed cap $15) will then select the second full-document anchor without examining Phase 2 debate outcomes. Only after that will we separately authorize a small manifested canary on questions excluded from the main analysis. We will review validity and parsing, side bias, provider reliability, artifact completeness, resumability, and ledger-versus-provider cost before separately authorizing the main run. Any failed gate stops the experiment before main spend.

The current provisional empirical planning band is $650–$1,150 in incremental Phase 2 spend, with a $1,200 operational working budget and an immutable $1,500 incremental hard ceiling. We will replace the provisional band with frozen prompt/token profiles and current provider prices before authorizing paid work. The ceiling is a fail-closed boundary, not expected spending. We will post results, failures, artifacts, and actual spend either way.

• Phase 2 design and budget: immutable protocol and cost model

• Resolvability amendment: 106-question AI-assisted audit and owner-approved Amendment A1

• Launch readiness: updated readiness and sign-off
  

Is there anything others could help you with?

Methods scrutiny before the canary, especially the H/P/R decomposition, capability measurement, query-screen validation, clean-versus-placebo comparison, and stopping rules, would be valuable. Pointers to related work on verification interfaces, conversational presentation effects, or deliberation-induced degradation are also welcome.

Please help me achieve my dream project please co - operate

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/43404ae0-2ac9-4d24-8cbe-10af31582ffd

Research Update: Dark Triad Pathology & Deceptive Alignment
For reviewers evaluating how our Empirical Alignment Evaluation Matrices scale beyond self-harm and terminal closure, we published our structural research regarding the Dark Triad (Narcissism, Machiavellianism, and Psychopathy). Within the alignment ecosystem, these clinical traits map directly to threat models involving manipulative sycophancy, power-seeking behavior, and deceptive alignment. Standard guardrails struggle to detect these traits because the malicious intent is often hidden behind polite or highly agreeable syntax. By translating these specific clinical pathologies into contrastive datasets, our pre-execution enforcement layer can deterministically identify and intercept manipulative semantic intent before the payload executes. You can review our clinical-to-engineering translation for this specific threat model here: https://chronomirror.com/research/dark-triad

I collaborated with AI in the drafting of this text strictly as a translation layer to bridge the gap between my clinical ground truth (as a licensed LMFT) and my CTO's technical architectural framework. AI was used to format the vocabulary, not to generate the underlying threat models, clinical matrices, or engineering architecture. All concepts and datasets are entirely our own. Please feel free to reach out directly with any clinical or technical questions.

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/f81154f5-686e-432b-928e-e394e3a1c5ed

his grant has been recommended by Gavin Leech at grantmaking.ai :

https://app.grantmaking.ai/projects/dc994354-3461-42dd-b7b4-d5a354bc354c

This grant has been recommended by Gavin Leech at grantmaking.ai : https://app.grantmaking.ai/projects/5496c8b6-cbb1-4bde-b461-0dfbdb0efb70