The gap between a system knowing and a system telling.

Standing

What I am qualified to say, what I am not, and how I say the difference.

This is the most important document in the repository. Everything else is production. This is the thing that decides whether any of it survives contact with someone who knows more than I do.

1 · The question, asked honestly

"You're a CS grad. Who are you to tell me how a Himalayan flood warning failed?"

That question is fair, it is coming, and it should be answered before it is asked — on camera, in the first thirty seconds, in my own words. A brand that has to be defended after the fact has already lost. A brand that answers first cannot be attacked on that ground at all.

The answer:

I'm a software engineer. I'm not a hydrologist and I'm not a geologist, and I don't claim to be either. The geology here comes from people who do it for a living and I cite every one of them. What I do is timing: when a system knew something, when it told someone, and what happened in the gap. That is a systems question, it's the question I've worked on professionally, and it's the one nobody was asking about this event.

Say it plainly. Do not apologise for it and do not oversell it. The limitation is the position: a person who is precise about the edge of their competence is more credible inside it, not less.

2 · What I am actually qualified on

The discipline is warning-chain latency: the interval between a system detecting a condition and a human being able to act on it, and every way that interval goes wrong. Detection thresholds. Sampling rate. Instrument survivability. The semantics of silence. Confirmation latency. False-positive budgets. Alert fatigue. The difference between detection and notification.

Every one of those is a software and systems problem. None of them is geoscience. They are the same problems whether the alarm sits on a river, a substation, a hospital ward, an aircraft, or a production service — which is why this discipline does not run out of subject matter, and why a person who works on software systems is the right person to hold it.

Two prior strategy documents in docs/ reached the same conclusion independently: research-cop.md calls the position "the builder who explains the physical systems behind technology, climate and infrastructure, using evidence people can inspect", and mus/research-mus.md calls it "systems interpreter … systems-measurement credibility." They were right and nothing built on it. This does.

The observation the whole brand rests on

	Nepal, 26 Aug 2026	Hawaii, 13 Jan 2018
System	national flood warning	ballistic missile alert (EAS/WEA)
Failure	did not fire when it should have	fired when it should not have
Sensor	worked; gauges reported correctly until destroyed	worked; there was no missile to detect
Institutional latency	38.8 min to issue a true alert	38 min to retract a false one
Root cause	confirmation logic tuned for slow-onset hazards	no second-person confirmation requirement at all

Two mass-alerting systems, opposite failures, effectively the same institutional delay. The sensor is almost never the problem. The decision is the problem, and the decision costs about the same whether it is right or wrong.

That is a human-factors and systems finding. It is exactly the kind of thing a software engineer should be the one to notice, and exactly the kind of thing a geologist would have no particular reason to look for.

3 · The evidence ladder

Every claim I make about my own work carries one of four labels, and I never let them blur. research-cop.md proposed this and it was the single best idea in the prior research.

Level	What it means	What I have
Peer reviewed	a journal or conference reviewed it	Sustainability 18(6):2799 (2026, second author) · ASCE WEWRC 2026 (second author) · IJEAST 2021 (first author)
Preprint	posted, not reviewed by anyone	EarthArXiv `10.31223/X5HN5H` (sole author) · TechRxiv 2025 (second of six)
Funded project	work in progress, result not published	PFAS–microplastic QSPR, Yudi Wu lab, Hinkley Center. Funding period ended Aug 2026
Production work	I built it, professionally	ControlKeel (public, ~1,386 commits) · Sparkshed · CVector · Prophet Town · Traktivity

The most independently attested thing I own is not a paper. It is six Clarivate-verified peer reviews for Engineering Management Journal (ISSN 2377-0643) — five in 2025, one in 2026 — confirmed directly from the ORCID public API. A journal asked me to referee, six times. Nobody can self-assert that. It belongs in every bio and it is currently in none of them.

And the honest counterweight, stated so nobody gets to reveal it: Google Scholar shows 5 total citations and an h-index of 1, and the most-cited item is a Kaggle dataset. That is an early-career record. The brand must not rest on academic authority, because there isn't enough of it to rest on. It rests on method, on falsifiability, and on being the person who builds the dataset.

4 · Things I may never say

Enforced by fac lint (family: standing), not left to discipline.

Never	Because
"my peer-reviewed paper" about the preprint	It is unreviewed. This single error would end the brand.
"as a hydrologist / geologist / climate scientist / Dr."	I am none of these.
"I found that the avalanche…" for a mechanism I read	The mechanism is ICIMOD's and DHM's. I cite it; I did not determine it.
"my research proves"	Research does not prove. Mine especially.
The PFAS R²=0.89 figure as a public credential	It appears nowhere but my own site. No publication backs it.
Voltage Park as a credential	No public record connects me to it. Unciteable is unusable.
HERA's benchmark numbers	The repository 404s. A number nobody can check is not a credential.

The general rule: if a stranger cannot verify it in under two minutes, it is not a credential. It may be true and still be unusable.

5 · How standing gets built, rather than claimed

Credentials I don't have cannot be acquired quickly. Standing can be built, and the way to build it is to become the source rather than to cite one.

The Warning Latency Archive. A public, versioned dataset: for each incident — hazard onset, detection time, confirmation time, dissemination time, lead time at each affected location, instrument state at failure, and the provenance of every figure. One row per incident, growing with every piece.

Nothing like it exists. Building it requires exactly what I have — data engineering, measurement discipline, and the patience to trace a number to its primary record — and none of what I don't. It is citable, it compounds, and after twenty incidents the answer to "who are you to tell me this" stops being a defence and becomes a fact:

I'm the person who built the dataset.

That is the long game, and it is the only route to standing that does not require permission from an institution.

6 · The dead

This section exists because it was missing, and its absence was the most serious gap in the whole plan. Everything above is about whether I am qualified. This is about the people the work is made of.

The first piece is about an event that killed 1,386 people in Nepal and 43 in Tibet, with 5,649 still missing. Recovery is ongoing. Families are still identifying remains. That is not background to an interesting timing problem — it is the reason the timing problem matters, and it imposes obligations that a systems analysis does not automatically carry.

Rules, not preferences.

No victim footage. No bodies, no close-ups of grief, no rescue imagery used as atmosphere. If a shot is doing emotional work rather than evidentiary work, it is not in the piece.
Never narrate a personal story I have not reported. I have not been to Rasuwa, I have not spoken to survivors, and I do not have reporting permission. Writing a scene I was not present for, from news footage, is fabrication wearing documentary clothes.
The death toll is stated once, precisely, with its source and its as-of date — and never in a title, a thumbnail or a hook. The number is evidence. It is not a retention device.
No disaster tourism and no ruin porn. The visual language is maps, gauge traces, timelines and documents. Not drone shots of destroyed villages set to music.
Credit local institutions and researchers by name. DHM, ICIMOD and the observatories did the work I am analysing. Their names go on screen where their findings are used, not in a description nobody reads.
If local collaborators ever contribute, pay them. Fixers, translators and local researchers are not free sources.
Nepali subtitles on Nepal work, if a Nepali speaker will check them. The people most affected should be able to read it.
Analysis is not blame. The finding is that a system optimised for one hazard met another. Naming an individual duty officer would be both cruel and wrong — the failure is in the design, which is the entire point.

The test, applied to every piece before it ships: would I show this to someone who lost a family member in it? If the answer needs a qualification, the piece is not finished.

7 · Before publishing, not after

Inviting correction after publication is necessary and it is not sufficient. A wrong claim that has already been watched by ten thousand people has done its damage, and the correction reaches a fraction of them.

So for every piece touching a physical hazard: send it to one person who works in that field, before it goes out. A hydrologist, a volcanologist, a seismologist, an emergency manager. Not for approval — for a chance to say "that's not what that means."

This costs nothing but an email and a week of lead time, and it eliminates the highest-severity risk on the register. Most researchers will read a short, specific, well-sourced piece from someone who is obviously not trying to embarrass their field. Ask narrowly: "I am not a hydrologist. Is my reading of the threshold logic wrong?"

Record who reviewed it and what they said. If they decline or do not reply, say so on the ledger page rather than implying a review that did not happen.

8 · Conflicts, employers, and what cannot be said

Forbidden from citing an employer as a credential is a separate question from forbidden from speaking about the work. Both apply.

Never disclose a former employer's proprietary architecture, client data, internal metrics or unreleased work. This binds regardless of whether an NDA is still active, and it binds hardest on the software pieces, where the temptation to use a real production example is strongest. Use public postmortems instead — they exist in abundance and they are free.
Disclose any relationship that could look like an interest — current employment, a grant, an institution, a former employer whose sector a piece touches. On the ledger page, in plain words.
No sponsorship, no affiliate links, no gifted equipment, for as long as the brand is establishing itself. There is nothing to disclose if there is nothing taken.
If a piece touches a field I am currently funded in or employed near, say so in the piece, not in a footnote.

9 · The rules of engagement

Invite domain review, publicly and by name. Every piece on a physical hazard ends with an explicit request for correction from people who work in that field. Asking to be checked is the cheapest credibility available and almost nobody does it.
Publish the uncertainty in the narrative, not in small print. The beat "what this does not establish" is not a disclaimer. It is the part researchers judge.
Never use a model output as a fact. State the range. The volume estimate in WT-001 spans a factor of 2.5 and is spoken as a range every time.
Corrections are dated and versioned. A brand that corrects visibly survives being wrong. One that edits silently does not survive being caught.
When someone who knows more turns up in the comments, hand them the floor. An expert correcting me in public, with my thanks, is worth more than any credential I could claim.