DEVLOG #6 Hey everyone!This is probably the last devlog for DOSEFIELD, at least for a while. It’s been an incredible journey—from the first rough prototype to something I’m genuinely proud to share. Thank you to everyone who followed along, tested the project, gave feedback, or simply read these updates. It really meant a lot.v2.3 is the “show your work” release. Nothing changed in the physics—and that’s exactly the point.The biggest addition is a new Methods page that renders the repository’s own METHODS.md and limitations table directly. That means anyone reading the website sees the exact same equations, assumptions, and all 12 limitations that exist in the source code. If the website and the repository ever disagree, the repository is the source of truth.Every page now also includes a provenance footer that’s generated automatically during the build. Instead of typing in a version number by hand, the site runs git rev-parse and the full test suite, then stamps something like:commit e22ef18 · 111/111 tests · verified 2026-07-18The build will actually fail if the tests don’t pass, so it’s impossible to accidentally display a “green” verification badge on a broken build.I also improved chart exports. Figures now render at 3200 px, and each exported chart includes its full configuration in the caption. That makes it much easier to trace a plot back to the exact settings that produced it, whether it’s used in a poster, report, or presentation.One thing I want to be completely clear about: this verification is about the software, not the physics. Passing 111 tests means the implementation behaves as expected according to those tests—it doesn’t prove the scientific model is perfect. The current validation remains the same: about 2× agreement with MSL/RAD, and the 0.67× absorbed-dose gap is still there, clearly documented.That’s exactly what this release is about: transparency over hype, reproducibility over screenshots, and being honest about what the model can—and can’t—do.Thanks for following this project. ❤️

DEVLOG #6 Hey everyone!This is probably the last devlog for DOSEFIELD, at least for a while. It’s been an incredible journey—from the first rough prototype to something I’m genuinely proud to share. Thank you to everyone who followed along, tested the project, gave feedback, or simply read these updates. It really meant a lot.v2.3 is the “show your work” release. Nothing changed in the physics—and that’s exactly the point.The biggest addition is a new Methods page that renders the repository’s own METHODS.md and limitations table directly. That means anyone reading the website sees the exact same equations, assumptions, and all 12 limitations that exist in the source code. If the website and the repository ever disagree, the repository is the source of truth.Every page now also includes a provenance footer that’s generated automatically during the build. Instead of typing in a version number by hand, the site runs git rev-parse and the full test suite, then stamps something like:commit e22ef18 · 111/111 tests · verified 2026-07-18The build will actually fail if the tests don’t pass, so it’s impossible to accidentally display a “green” verification badge on a broken build.I also improved chart exports. Figures now render at 3200 px, and each exported chart includes its full configuration in the caption. That makes it much easier to trace a plot back to the exact settings that produced it, whether it’s used in a poster, report, or presentation.One thing I want to be completely clear about: this verification is about the software, not the physics. Passing 111 tests means the implementation behaves as expected according to those tests—it doesn’t prove the scientific model is perfect. The current validation remains the same: about 2× agreement with MSL/RAD, and the 0.67× absorbed-dose gap is still there, clearly documented.That’s exactly what this release is about: transparency over hype, reproducibility over screenshots, and being honest about what the model can—and can’t—do.Thanks for following this project. ❤️

Devlog – Day 2: UI Improvements & Coin CollectionToday I focused on improving the core gameplay loop and adding user interface elements to make the game feel more complete.What I worked onAdded a coin counter that updates whenever the player collects a coin.Connected the score system to a Label inside a CanvasLayer, ensuring the UI stays fixed on the screen even when the camera or player moves.Continued refining the coin collection logic, making sure the score increases correctly when a coin is picked up.Began implementing a Congratulations message that appears after collecting all the coins. While working on this, I encountered a node path error (Node not found), which helped me better understand how Godot searches for nodes relative to the current scene.Explored how to use CanvasLayer to display UI elements such as score, win messages, and future game notifications.Learned about different ways to create a countdown timer, including using Godot’s built-in Timer node and creating a timer with _process(delta).ChallengesThe biggest issue today was accessing UI nodes from the correct script. I learned that using an incorrect node path causes Godot to search relative to the current node, resulting in a “Node not found” error. Understanding the scene tree and node hierarchy made it much easier to troubleshoot these issues.Next StepsFinish the “Congratulations” screen after all coins are collected.Add a countdown timer to create a time-based challenge.Implement a “Time’s Up” or “Game Over” screen if the player runs out of time.Continue polishing the UI and overall gameplay experience.Overall, today was focused on connecting gameplay mechanics with the user interface. Although I ran into a few errors, they helped me gain a better understanding of Godot’s scene tree and node system, making future UI development much easier.

Devlog #08

Hello everyone(˶ᵔᗜᵔ˶)ﾉﾞ,

Welcome to Devlog #08 of AniSuffle.

Hope you all are doing great.

Okay, now let me explain quickly of my recent changes or update on the site.

I am not sure but maybe this will be abit shorter devlog, maybeeee(ᵕ—ᴗ—)…. since most of the work is about backend (so nothing flashy to explain) also I will try to not bore anyone reading this.[also i try keeping the devlogs raw and unfiltered]

Okay now lemme explain.

Save Button & Auth Feature

Sooo, the feature I have recently added to my site, actually not added, am still working on it is the save button and also adding a auth feature (the login and signup feature to be more simple =)).

Its not complete though.

And one more thing, you definitely dont need to login or signup to use any of the features and tools I have made so far beacuse I understand that signing up is such a pain, I mean at least to me it isss.

But there is one feature I want to add, and for this I think the signup is necessary.

Now let me expalin how the save feature is going to work.

It might be abit different as I am still working on it, I will just tell what I am planning to do.

** Why am I writing this devlog now?**

And before that If you ask why am I writing a devlog if I have not done the job, then ummm…∘ ∘ ∘ ( °ヮ° )

Actually I am working on the backend and I am scared I might mess anything up, as I am not too confident on backend and storing user data safely is my top priority( ◡̀_◡́)ᕤ whenever I am dealing with the backend and while doing this I didnt realize that I have already 5 or maybe 6 hours I am not sure but maybe its around 6 hours of time logged already so I thought of updating the devlog, even though I am in the middle of the function (I mean the development process(ᵕ ó ᴗ ò)).

I feel like I sound abit unclear (ó﹏ò｡)ummm, lemme just explain properly how the save feature is going to (or supposed to) work.

So there are two scenerios.

** When not signed in**

When you are not signed it, you will still be able to access all the feature of the site, even the save button.

But there is a catch.

All your saved animes/mangas will be stored on the localstorage.

Just a small explaination just in case you have no idea of what localstorage is, ummm…

In simple terms you can think it as the browser’s storage area, its typically around 4 MB or 5 MB i assume, but they should be more than enough to us as we are just storing the anime/manga url, source, id and stuff.. lets not go too deep into itദ്ദി(˵ •̀ ᴗ - ˵ ) ✧.

So you will still be able to save animes/mangas but you would need to be on the same browser with same browser profile to access those info.

When signed in

When you are signed in, your saved infos will be stored on the database of the server and you will be able to access them from any device and any browser. and This is the reason I am adding the Singup feature

Oh…

The devlog doesnt seems small any more. I’m i’m i’m sorry for that(ㅅ •᷄ ₃•᷅ )

Lemme wrap up quick umm but wait I will drop the screenshot of the site by pointing at the save button.

Currently its with no css, but dont worry I will update that ugly default button design (and maybe position as well) as soon as i finish my backed(・–・;)ゞ

I guess thats it for this devlog , If I forget to mention anything , I will surely update it in the next devlog.

If you didnt understand any of the point , please do comment and I will try to explain you there ദ്ദി◝ ⩊ ◜.ᐟ

Thank You all so much for reading.

Have a nice day =)

Hey everyone!Here’s a quick update on VeritasCore.If you haven’t seen it before, VeritasCore is an AI auditing tool. Instead of building another language model, it evaluates existing ones. You point it at a deployed AI model, it automatically launches red-team attacks looking for jailbreaks, bias, prompt injection vulnerabilities, and behavioral drift, then produces a cryptographically signed compliance certificate using Ed25519 so the results can be independently verified.The MVP already works. My goal for this hackathon is something different: making the entire pipeline run on AMD’s AI ecosystem using ROCm 7.2, PyTorch 2.9, and vLLM 0.16.0.Before writing a single line of integration code, I wanted to answer one question:Will this actually run on ROCm?A surprising number of AI projects quietly depend on NVIDIA-only libraries. Things like FlashAttention, xFormers, bitsandbytes, custom CUDA kernels, or even hardcoded cuda:0 references can completely derail a port.So my first task wasn’t coding—it was detective work.I went through the repository dependency by dependency, expecting to uncover compatibility problems.Instead, I found… almost nothing.The reason is surprisingly simple: VeritasCore doesn’t perform inference itself. It’s a black-box auditor that communicates with models over HTTP. The GPU only matters for the model being audited—not for the auditor.That completely changed the migration strategy.Instead of trying to rewrite the auditor, I can simply replace the scripted demo endpoint with a real open-source model served through vLLM on AMD hardware.To prepare for that, I built a small smoke test that will:verify PyTorch is using the HIP/ROCm build,confirm the AMD GPU is visible,and send a real inference request through the smallest practical model before scaling up.So far, I haven’t used a single second of GPU time. Every test has run entirely on CPU while preparing the environment.The next milestone is the exciting one: launching the first inference on the AMD notebook and seeing what actually breaks.That’s usually where the real engineering begins.

Cosmos Devlog 2 🪐✨ - What I would be doing today:

• Make the site more creative.

• Add some space facts.

• Try to finish the first page of the website.

• Maybe add some images.

Note: I am so sorry but I have been staying a little busy lately because of school work so I will try my best to complete making the site as fast as I can! 🫶🏻

Hey everyone!Here’s a quick update on VeritasCore.If you haven’t seen it before, VeritasCore is an AI auditing tool. Instead of building another language model, it evaluates existing ones. You point it at a deployed AI model, it automatically launches red-team attacks looking for jailbreaks, bias, prompt injection vulnerabilities, and behavioral drift, then produces a cryptographically signed compliance certificate using Ed25519 so the results can be independently verified.The MVP already works. My goal for this hackathon is something different: making the entire pipeline run on AMD’s AI ecosystem using ROCm 7.2, PyTorch 2.9, and vLLM 0.16.0.Before writing a single line of integration code, I wanted to answer one question:Will this actually run on ROCm?A surprising number of AI projects quietly depend on NVIDIA-only libraries. Things like FlashAttention, xFormers, bitsandbytes, custom CUDA kernels, or even hardcoded cuda:0 references can completely derail a port.So my first task wasn’t coding—it was detective work.I went through the repository dependency by dependency, expecting to uncover compatibility problems.Instead, I found… almost nothing.The reason is surprisingly simple: VeritasCore doesn’t perform inference itself. It’s a black-box auditor that communicates with models over HTTP. The GPU only matters for the model being audited—not for the auditor.That completely changed the migration strategy.Instead of trying to rewrite the auditor, I can simply replace the scripted demo endpoint with a real open-source model served through vLLM on AMD hardware.To prepare for that, I built a small smoke test that will:verify PyTorch is using the HIP/ROCm build,confirm the AMD GPU is visible,and send a real inference request through the smallest practical model before scaling up.So far, I haven’t used a single second of GPU time. Every test has run entirely on CPU while preparing the environment.The next milestone is the exciting one: launching the first inference on the AMD notebook and seeing what actually breaks.That’s usually where the real engineering begins.

DEVLOG #5 (might be the last devlog) Hey! It’s been 11 days since the last devlog. DOSEFIELD wasn’t abandoned—I was just busy building instead of writing.This update was really about two things: making the code cleaner and making the site feel like it belongs in a space mission.The first issue was hidden in the background. The NASA validation numbers on the website were calculated separately from the ones used in my research. The math was identical, but it existed in multiple places. That meant one future change could easily make the numbers disagree.So I refactored everything to use a single source of truth. Now every result comes from the same function, making the site much easier to maintain and much harder to break.Then I focused on the design. The old version worked, but it didn’t feel like DOSEFIELD. I redesigned the interface with a mission-control style, added a cleaner layout, and simplified the visuals. I also removed a lot of unnecessary effects—less glow, fewer gradients, and a more purposeful look.After all those changes, I reran every test. All 107 tests still pass, and the stopping-power calculations remain within 1.55% of NIST reference data, exactly as before.There’s still one limitation: my model predicts about 67% of the radiation dose measured by NASA during the trip to Mars. That’s because it doesn’t yet simulate secondary particle production inside spacecraft shielding. It’s an important limitation, and it’s clearly explained on the website rather than hidden.The biggest lesson from this update wasn’t about physics—it was about revisiting old work. Good code doesn’t duplicate logic, and good design doesn’t rely on effects to look impressive. Sometimes the best improvement is simply cleaning up what you already built.

Brief description:Creating display UI and planning the system architecture.

I am currently designing elements of UI that will be used to modify parameters such as modes, colors, speed and brightness.
Desining the color wheel was the hardest thing so far because I faced some problems with the framebuf library. (different way of storing information than my display library used) I used chatGPT to help me with this fix.

I have also written down all the modes that I want to create and also defined what parameters I want to change on them using the UI. I have also thought of a way how to store those parameters and how to run the modes. I am planning to create functions for each mode and then run them as threads.

I have also been solving some problems with HackaTime. (I have worked for at least 5 hrs not 15 mins) Because it does not support Thonny, so I decided to write the code in VS code and then run it on my ESP32 using Thonny.

DEVLOG #5 (might be the last devlog) Hey! It’s been 11 days since the last devlog. DOSEFIELD wasn’t abandoned—I was just busy building instead of writing.This update was really about two things: making the code cleaner and making the site feel like it belongs in a space mission.The first issue was hidden in the background. The NASA validation numbers on the website were calculated separately from the ones used in my research. The math was identical, but it existed in multiple places. That meant one future change could easily make the numbers disagree.So I refactored everything to use a single source of truth. Now every result comes from the same function, making the site much easier to maintain and much harder to break.Then I focused on the design. The old version worked, but it didn’t feel like DOSEFIELD. I redesigned the interface with a mission-control style, added a cleaner layout, and simplified the visuals. I also removed a lot of unnecessary effects—less glow, fewer gradients, and a more purposeful look.After all those changes, I reran every test. All 107 tests still pass, and the stopping-power calculations remain within 1.55% of NIST reference data, exactly as before.There’s still one limitation: my model predicts about 67% of the radiation dose measured by NASA during the trip to Mars. That’s because it doesn’t yet simulate secondary particle production inside spacecraft shielding. It’s an important limitation, and it’s clearly explained on the website rather than hidden.The biggest lesson from this update wasn’t about physics—it was about revisiting old work. Good code doesn’t duplicate logic, and good design doesn’t rely on effects to look impressive. Sometimes the best improvement is simply cleaning up what you already built.

Vibe Check — Devlog

said last devlog i’d be tackling the UI redesign next. did that. also did about four other things i didn’t plan on. classic me.

two days, and somehow: bug fixes, the redesign, AI integration, a whole landing page, and deployment setup. CSS changes enough to make me question my existence 💔

bugs that were silently ruining everything

found out half the buttons in the app weren’t even styled because the css class they used literally didn’t exist 😭

also discovered template search wasn’t searching anything because the input id was missing.

the search bar looked functional.
it was not.
meow.

fixed a bunch of cursed unicode issues too because apparently some checkmarks had transformed into ancient artifacts from another dimension.

the redesign arc 🥀

this one was planned, but it still spiraled way harder than expected.

changed one thing. then another. then suddenly popup.css was over 700 lines.

goodbye neon cyberpunk.
hello warm golds, soft reds, glass panels, crystal backgrounds, rounded corners and way too many blur effects.

the whole thing feels a lot calmer now.
less “rgb gaming keyboard”
more “expensive thing i can’t afford” :3

ai brain upgrade

probably the biggest change, and definitely not planned.

vibe check can now use Cerebras gpt-oss-120b for prompt enhancement.

ended up building support for:

• local development
• chrome extension mode
• production deployment

all using the same enhancement pipeline.

if ai dies the app automatically falls back to local enhancement so users don’t get hit with a giant error message.

because nobody likes giant error messages.

built a whole landing page because apparently i enjoy suffering

didn’t even plan this one.

but now there’s:

• animated hero section
• glassmorphism everywhere
• feature cards
• demo section
• platform showcase
• responsive layout

and enough floating visual effects to make my gpu slightly concerned.

production stuff nobody will notice

added deployment configs.
serverless functions.
environment variables.
request validation.
api key protection.
cors handling.

all the boring stuff that becomes very exciting when it’s missing.

stats

files modified: basically yes
popup.css: 730 lines
popup.js: 1300+ lines

new files:

• landing page
• serverless ai endpoint
• deployment config

:3

Devlog #4 — Heavy Elements Cut, Liquid Hydrogen Locked In

Lead and titanium were off by 50%. I didn’t hide it.

My model tracks how particles slow down inside matter. For heavy elements like lead and titanium, you need a correction for the atom’s electron shells — skip it, and your numbers drift by half the actual value. I haven’t built that correction yet. Faking the results to look clean would gut the whole point of the model. So heavy elements are out for now.

Liquid hydrogen sits at the opposite extreme. One electron, no shell complexity — the model handles it without shortcuts. I checked against NIST’s official proton data: 0.14% deviation across the full energy range. In physics terms, that’s a bullseye.

Five Materials, One Hierarchy

I ran five materials together — liquid hydrogen, methane, polyethylene, water, and aluminum — and tested them as a chain. Two things had to hold: thicker shielding means lower dose, and going from hydrogen to aluminum, dose has to climb, because light elements stop protons better.

Both held, with no exceptions. Polyethylene and water differ by just 3% in electrons per gram — the model caught even that gap correctly.

The sharpest result: at 40 g/cm², liquid hydrogen cuts dose by 44% compared to aluminum. That’s why some spacecraft designs wrap the crew compartment in hydrogen tanks — fuel and radiation shield in one.

All five materials are now locked into regression tests. Total: 103 green tests in CI.

One Function, One Truth

The dashboard and the generated reports used to calculate their numbers separately. Two parallel code paths mean two places for drift to appear. Now both pull from a single shared function. The number on screen and the number in the report are physically incapable of disagreeing.

Devlog #4 — Heavy Elements Cut, Liquid Hydrogen Locked In

Lead and titanium were off by 50%. I didn’t hide it.

My model tracks how particles slow down inside matter. For heavy elements like lead and titanium, you need a correction for the atom’s electron shells — skip it, and your numbers drift by half the actual value. I haven’t built that correction yet. Faking the results to look clean would gut the whole point of the model. So heavy elements are out for now.

Liquid hydrogen sits at the opposite extreme. One electron, no shell complexity — the model handles it without shortcuts. I checked against NIST’s official proton data: 0.14% deviation across the full energy range. In physics terms, that’s a bullseye.

Five Materials, One Hierarchy

I ran five materials together — liquid hydrogen, methane, polyethylene, water, and aluminum — and tested them as a chain. Two things had to hold: thicker shielding means lower dose, and going from hydrogen to aluminum, dose has to climb, because light elements stop protons better.

Both held, with no exceptions. Polyethylene and water differ by just 3% in electrons per gram — the model caught even that gap correctly.

The sharpest result: at 40 g/cm², liquid hydrogen cuts dose by 44% compared to aluminum. That’s why some spacecraft designs wrap the crew compartment in hydrogen tanks — fuel and radiation shield in one.

All five materials are now locked into regression tests. Total: 103 green tests in CI.

One Function, One Truth

The dashboard and the generated reports used to calculate their numbers separately. Two parallel code paths mean two places for drift to appear. Now both pull from a single shared function. The number on screen and the number in the report are physically incapable of disagreeing.

Changing to a real server & a new TACTICAL UI

Added a new Dropdown menu to the TACTICAL page to filter threats by layers and fully changed the backend to the Hack Club Nest server!

The biggest friction this week was dealing with my old Render backend constantly going to sleep, which made the web app feel broken to new users. I finally set up my FastAPI app with PM2 so it stays awake 24/7.

On the frontend, I built a sleek new dropdown to change between Earthquakes, Floods, Storms, and Volcanoes. The hard part was getting the map layers to play nicely together, toggling the new NASA API’s kept overwriting my core 6,000+ wildfire array! I had to rewrite the logic to separate the Leaflet layers so the map can stays fast and doesn’t wipe your data when you switch views.

Right now, I am still trying to fix some bugs and improving the CO2 graph, I am also planning on updating my README.md to explain the new features (better).

THANK YOU FOR READING!
(I am almost at 20 hours of coding omg, I may need to add a special feature for when it happens. Any ideas or improvements are really appreciated!)

Finished the code section!

I finished the code section for my website, finally!

Photography

I rearranged the photos from the “scene” thing into just one continuous thing bcs the scene for me would’ve been too hard for me to design UX and UI around. Also added back scrolling using arrow keys!

Code

Finished everything including projects! This took alot of time and alot of debugging. The code backgrounds are actual text styles with CSS.

EVERYTHING

made the website more responsive!

-ok

Devlog #3 — DOSEFIELD Is Live 🚀Hi! Long time no see.DOSEFIELD is now live: https://izbanovj3-prog.github.io/DOSEFIELD/ The entire dosimeter now runs directly in your browser — no installation required. That includes the controls, dose-vs-thickness chart, particle fragmentation toggle, and validation panel.Under the hood, the project is built with Vite and automatically deployed to GitHub Pages through a GitHub Actions workflow. Every push to the main branch triggers a fresh build and deployment. The setup is intentionally simple: deployment uses GitHub’s built-in Actions token, with no external services and no additional secrets.The only challenge in this release wasn’t physics — it was infrastructure. The first deployment failed because GitHub Actions cannot automatically enable GitHub Pages for a repository. The workflow reached that permission boundary and stopped. After enabling Pages in the repository settings and rerunning the workflow, everything deployed successfully.Once the site was live, I verified that all critical assets were being served correctly. The page, stylesheets, and, most importantly, the Web Worker bundle all return HTTP 200 responses with the correct content types.That Web Worker is particularly important because it handles the species-by-species dose integration calculations off the main UI thread. In practice, this means the interface remains responsive while the physics calculations run in the background.No physics models changed in this release, and the known limitations remain the same. This phase was focused entirely on one goal: shipping a fully accessible browser version of DOSEFIELD.The live demo link is now featured at the top of the README.

Devlog #3 — DOSEFIELD Is Live 🚀Hi! Long time no see.DOSEFIELD is now live: https://izbanovj3-prog.github.io/DOSEFIELD/ The entire dosimeter now runs directly in your browser — no installation required. That includes the controls, dose-vs-thickness chart, particle fragmentation toggle, and validation panel.Under the hood, the project is built with Vite and automatically deployed to GitHub Pages through a GitHub Actions workflow. Every push to the main branch triggers a fresh build and deployment. The setup is intentionally simple: deployment uses GitHub’s built-in Actions token, with no external services and no additional secrets.The only challenge in this release wasn’t physics — it was infrastructure. The first deployment failed because GitHub Actions cannot automatically enable GitHub Pages for a repository. The workflow reached that permission boundary and stopped. After enabling Pages in the repository settings and rerunning the workflow, everything deployed successfully.Once the site was live, I verified that all critical assets were being served correctly. The page, stylesheets, and, most importantly, the Web Worker bundle all return HTTP 200 responses with the correct content types.That Web Worker is particularly important because it handles the species-by-species dose integration calculations off the main UI thread. In practice, this means the interface remains responsive while the physics calculations run in the background.No physics models changed in this release, and the known limitations remain the same. This phase was focused entirely on one goal: shipping a fully accessible browser version of DOSEFIELD.The live demo link is now featured at the top of the README.

Day #1: the hard part is in, now I find out if it’s right

I’m building DOSEFIELD, a 1D model that estimates how much radiation an
astronaut absorbs on a deep-space mission — and how much shielding actually
helps. Cosmic rays in, dose-equivalent out.

What’s already solid: the stopping-power core matches NIST PSTAR reference data
to within 1.6%, and behind 10 g/cm² of aluminium at solar minimum the model
gives 1.96 mSv/day — about 0.70 Sv over a 360-day Mars cruise. That’s 17% past
NASA’s 600 mSv career limit. A round trip to Mars quietly blows through the
radiation an astronaut is allowed for their entire career. That’s the reason
this project exists.

But the first version only tracked primary particles, and it showed: my
aluminium, polyethylene and water curves were sitting almost on top of each
other. That’s physically wrong — polyethylene should shield noticeably better,
because hydrogen is good at breaking up heavy ions. The missing piece is nuclear
fragmentation.

So this week I implemented it — real fragmentation cross sections
(Bradt–Peters), not a fudge factor tuned to match NASA’s measured value. The
material difference has to come out of the physics: hydrogen has the shortest
nuclear interaction length per g/cm², so it should win on its own. No parameter
is fit to the answer.

Now I’m validating it, and I’m writing the test down BEFORE the result so I
can’t quietly move the goalposts. If the physics is right, I should see four
things: the curves separate (polyethylene below aluminium), aluminium flatten
out at depth, the mean quality factor drop from 4.82 toward ~3.5–4, and the dose
move closer to the real MSL/RAD cruise measurement. If they don’t, the model is
wrong and I’ll say so.

Numbers in the next entry. Either it works or it doesn’t — that’s the whole
point of logging the test first.

What it still isn’t: 1D, simplified fragmentation, not a replacement for NASA’s
HZETRN. Every value traces to a cited source, and the validation suite re-runs
on every change.