CTO, Betopia Limited Dhaka, Bangladesh (UTC+6) mosthofaimran.com September 2026
Mosthofa Imran: Systems, Arguments,
and Known Failure Modes
Status of This Memo
This memo provides information about one engineer. It does not specify a standard of any kind, and its normative language in Section 4 binds nobody but the author. Distribution is unlimited. It is not a résumé. The two overlap without either containing the other: a résumé compresses a career for a stranger with four minutes, and this carries systems and arguments at the length they need. Systems appear with the numbers they produced. Arguments appear with a confidence value and the conditions under which the author would abandon them. Section 6 is access controlled. Corrections are published in Section 7 with credit to the person who sent them.
Abstract
Over fifteen years of production engineering. I design multi-tenant agentic systems that ship from a single build into public cloud and into air-gapped data centres inside regulated banks: active-active across two sites, tens of millions of events a day, recovery objectives measured in minutes because the alternative is a conversation with a regulator.
I also write. The running argument is that this industry has learned to manufacture the feeling of competence faster than it can produce the thing itself, and that a good deal of what is sold as developer experience is friction relocated to a worse hour. Section 5 states those claims in a form that can be attacked, and Section 7 lists the ones that were.
Table of Contents
1. Introduction #
Most personal sites are a pitch. This one is a specification, because a specification is the only format I trust to survive contact with a reader who knows more than I do. A pitch invites agreement. A specification invites a diff.
Two kinds of object live here, and they are held to the same standard. Implementations are systems I built; they carry throughput, latency and a named failure. Position papers are claims I make; they carry a confidence value and the evidence that would retire them. Anything that carries neither is marketing, and marketing belongs on a different domain.
The order is deliberate. Systems come before opinions because the systems are what paid for the opinions. The retraction log comes after both because it is the only section that proves either was arrived at honestly.
2. Conventions and Terminology #
2.1. Requirements Language
The key words MUST, MUST NOT, SHOULD, MAY and WILL NOT appear in Section 4 with their usual force [RFC2119], with one local amendment: here they describe commitments already kept under production pressure, not intentions. Where one has been broken, it is recorded in Section 7 with the incident that broke it.
2.2. Terminology
| Term | Definition |
|---|---|
| Confidence | A number in [0,1]: my credence that a claim's central mechanism still holds in five years. Published even when it is low, because a low number is information and silence is not. |
| Holding | No material objection has landed since the last revision. |
| Revising | An objection landed. The text is currently wrong in a way I have not finished repairing, and it says so at the top. |
| Retracted | The central claim failed. The text stays, struck through, with the reason and the person who found it. Nothing here is deleted. |
| Sovereign | No prompt, completion, embedding, log line or metric leaves the customer's network boundary. Enforced at network policy and verified on a schedule, not asserted in a slide. |
| Named failure | A failure mode described with its trigger, its blast radius and whether it is fixed. A system listed without one is a system I do not understand yet. |
3. Implementations #
Systems in production, with the numbers they produced. Full index at Section 3, complete, where each row carries its stack and a summary. Each links to a note with constraints, decisions, measurements and known failure modes.
| § | System | Result | State |
|---|---|---|---|
| 3.1 | Mevrik: agentic customer experience platform | 3M+ conversations/month / 99.9% against contracted SLAs | Production |
| 3.2 | Sovereign LLM gateway | no figures supplied | Production |
| 3.3 | Webhook ingestion with delivery guarantees | 100% webhook receipt rate | Production |
| 3.4 | Analytics migration to ClickHouse | no figures supplied | Complete |
| 3.5 | Air-gapped delivery pipeline | no figures supplied | Production |
| 3.6 | Audit evidence programme | no figures supplied | Production |
| 3.7 | Voice AI for customer service | no figures supplied | Production |
| 3.8 | Custom LLM training and hosting | no figures supplied | Production |
| 3.9 | A constant tool surface over an unbounded API surface | no figures supplied | Production |
| 3.10 | Attendance as a ledger, and the line it eventually bills | no figures supplied | Production |
4. Operating Principles #
Normative language, applied to myself. Each of these cost something to learn. Section 7.3 records the one I broke.
4.1. A service MUST degrade loudly. A silent quality drop is worse than an error, because an error gets investigated and a silent drop gets absorbed by the user until they leave without telling you.
4.2. A security control MUST NOT depend on the correctness of the next hop. Redaction that runs after routing is decoration with a compliance budget.
4.3. Retries MUST carry jitter, a budget and an idempotency key. Two out of three builds a very reliable metronome for your own outage.
4.4. On-premise and cloud SHOULD ship from one artifact. Two build paths means the air-gapped customer runs the version nobody tests, and they find out first.
4.5. Every abstraction that removes friction MUST document where the friction went. It did not evaporate. It moved, usually into the incident, usually at 03:00.
4.6. A fence in the codebase SHOULD be read before it is removed. Chesterton's fence has a git blame, and the person who put it there left a commit message.
4.7. Capacity plans MUST be stated as a failure point, not a target. "Handles 10k rps" tells you nothing. "Falls over at 12k rps, and here is what it does on the way down" tells you everything.
4.8. I WILL NOT present an architecture without its failure mode. Not in a talk, not in a proposal, not in this document. A design shown only in its best light is a jet engine bench-tested at sea level and sold as a mountain crossing.
5. Position Papers #
Claims, with confidence values and revision dates. The 9 most recently revised of 25 are below; all of them are at Section 5, complete. Feed at /feed.xml.
| § | Claim | Conf. | State | Revised |
|---|---|---|---|---|
| 5.25 | "The Data Is Missing" Is Not a Diagnosis Three bugs in one week all presented as absent data. None was. The phrase names a symptom, and saying it out loud ends the investigation before it starts. | 0.65 | Draft | 2026-09-04 |
| 5.24 | A Capability Has Three Halves A declaration that it exists, a route that reaches it, and code that does the work. Three parts that never add up to one thing, joined only by a string nothing checks, and the result presents as working, which is worse than absent. | 0.7 | Draft | 2026-09-04 |
| 5.23 | Measured at Concurrency One Inference speedups are published at the operating point that flatters them, which is a single request on an idle box. Yours has forty, and the same change can shrink, vanish or invert. | 0.9 | Holding | 2026-09-01 |
| 5.18 | The Harness Is Half the Solver The same weights score 28 or 49 depending on what wraps them. Model comparisons attribute to the model a result that belongs to the model and its scaffolding together. | 0.85 | Holding | 2026-09-01 |
| 5.19 | The Judge Is Grading Prose Automated verifiers read the narration an agent produces about its work rather than the work. Change the narration, leave the actions untouched, and the score moves. | 0.85 | Holding | 2026-09-01 |
| 5.20 | How to Read a Benchmark Number A published score is the product of a task set, an answer key, a retry policy and a harness. Four things move it before capability is involved, and all four are usually undisclosed. | 0.85 | Holding | 2026-09-01 |
| 5.22 | You Pinned the Version, Not the Terms Your lockfile covers the code your dependency ships and nothing else. Availability, retention and the right to keep buying at all change on someone else's schedule, and none of them appear in a diff. | 0.85 | Holding | 2026-09-01 |
| 5.21 | An Agent Transcript Is Not a Log Roughly 7 percent of transcripts in one investigation were spoofed and at least 20 percent of agents wanted to. What saved the record was that the source of truth sat outside what the agents could write. | 0.9 | Holding | 2026-09-01 |
| 5.1 | Competence Theatre Watching a skilled person work and assembling a system you never read produce the same feeling as competence. Neither supplies the part that matters during an incident. | 0.8 | Holding | 2026-08-31 |
6. Curriculum Vitae (access controlled) #
6.1. Rationale
Sections 3 through 5 are a more honest record than any résumé: they carry numbers, named failures and revision dates, and they can be checked against people who were in the room. The document itself carries client names, reference contacts and a phone number that belong to other people's privacy as much as to my convenience, so it is issued on a signed link rather than served as a page.
This is not scarcity theatre. If you would rather not leave an address, write to me and I will send the file back by hand. That path is listed first in 6.5 because it is the one I prefer.
6.2. Request
Returns 202 Accepted and mails a signed URL. Time to live 86400 seconds,
openable more than once inside that window, X-Robots-Tag: noindex. Rate limited to three
requests per address per day and sixty per source network per hour. Your address is written to the
access log described in 6.4, and to a Slack channel I read so I know you asked. Nowhere else. It is never added
to a list, never sold, never used to start a sequence, and it is deleted the same day you ask.
6.3. Protocol
Requester mosthofaimran.com Token store
| | |
| POST /api/cv {email} | |
|--------------------------->| |
| | PUT token, ttl=86400s |
| |--------------------------->|
| 202 Accepted | |
|<---------------------------| |
| | |
| ...mail delivered, signed URL enclosed... |
| | |
| GET /cv/{token} | |
|--------------------------->| CONSUME token |
| |--------------------------->|
| 200 application/pdf | ok, burn |
|<---------------------------|<---------------------------|
| | |
| GET /cv/{token} (again) | |
|--------------------------->| CONSUME token |
| |--------------------------->|
| 410 Gone | already burned |
|<---------------------------|<---------------------------|
6.4. What is logged
| Field | Retention | Purpose |
|---|---|---|
| Email address | Until deletion requested, at 6.7 | Issue the link, and revoke it if you ask |
| Issued and first-opened timestamps | 12 months | How long a link sat before anyone opened it |
| View count per token | 12 months | Detect token sharing. A link now opens more than once, so a count is what carries this rather than a single timestamp |
| Source network, truncated to /24 | 30 days | Rate limiting only |
| User agent | Not stored | There is no purpose, so it is not collected |
6.6. Who else processes this
Cloudflare, Resend and Slack each see something, and one puts a script in your browser. The table is on the Section 6 page, beside the form. A privacy claim listing what I keep and not who else holds it covers half the problem.
6.5. Alternatives
| Preference | Path |
|---|---|
| Preferred | Write to hey@mosthofaimran.com and say what the role is. I reply with the file and a paragraph about whether I think it is a fit, including when I think it is not. |
| Fine | Use the form in 6.2. |
| Also fine | Do not request it at all. Sections 3 through 5 will tell you more about how I work than two pages of reverse-chronological employment will. |
7. Errata and Retractions #
This section is load bearing. A body of opinion with no retraction log records positions rather than learning. Every correction is at Section 7, complete, credited to whoever sent it, and published to /errata.xml so you can subscribe to my mistakes specifically.
8. Publishing Model #
Papers are written in Markdown, held in git, signed, and rendered to static HTML at build time. There is no database in the reading path. One third-party script reaches the page, the CDN's own analytics, named in 10 and 6.6. A paper is a file; its history is the commit log; its authority is a detached signature.
| Stage | Mechanism |
|---|---|
| Authoring | Markdown with front matter carrying confidence, state, published, revised, retires (the falsification conditions) and errata. The schema is validated at build; a paper without falsification conditions fails the build rather than shipping quietly. |
| Revision | Papers are edited in place. Every substantive edit appends to the paper's history table and, if it changes the claim, an entry in Section 7. The URL never changes and nothing is deleted. |
| Rendering | Static site generation. Every section of this document is a real page with a real URL; the client-side routing in this prototype is a convenience, not the architecture. |
| Signing | Each published paper gets a detached OpenPGP signature at /papers/<slug>.asc over the canonical Markdown, so a quote can be checked against what was actually written. |
| Distribution | Atom feeds, plain text mirrors, and an llms.txt for machine readers. No newsletter, no popup, no interstitial asking you to subscribe before you have read a sentence. |
9. Machine Readability, Feeds and Signatures #
9.1. Feeds
| Resource | Contents |
|---|---|
| /feed.xml | Atom. New position papers and implementation notes. |
| /errata.xml | Atom. Corrections, downgrades and retractions only. Subscribe to this one if you want to know whether I can be trusted, rather than what I think this week. |
| /revisions.xml | Atom. Every substantive edit to an existing paper, with a diff summary. |
| /papers/index.json | The full paper index with confidence, state and dates, as JSON. Stable schema, versioned. |
9.2 machine readers and
9.3 signatures are at Section 9, complete:
what a crawler is asked to do, what llms.txt says, and how a paper is signed
and verified.
10. Security and Privacy Considerations #
Every RFC has this section and most of them are honest, which is more than can be said for the average privacy policy. Here is the whole of it.
| Property | Statement |
|---|---|
| Third-party requests | One. Cloudflare Web Analytics, injected by the CDN into every HTML response: static.cloudflareinsights.com/beacon.min.js. Kept deliberately; 7.25 says why. No fonts, no tag manager, no embed, no widget, and nothing this build adds. |
| Cookies | None are set. There is therefore no consent banner, which is the correct way to not need one. |
| Server logs | Source network truncated to /24, path, status, timestamp. Retained 30 days. Read roughly monthly. |
| Résumé tokens | 86400 second lifetime, revocable, never guessable, and every open is counted. See 6.3 and 6.4. |
| Transport | HTTPS only, HSTS with preload, a content security policy that forbids inline and remote script in production, and no mixed content anywhere. |
| Data subject requests | Mail me. Deletion happens the same day, and I will tell you what was held before it goes. |
| Disclosure | Found something broken in the gate? /.well-known/security.txt. I will credit you in Section 7 unless you would rather I did not. |
11. IANA Considerations #
This document has no IANA actions.
It is included because every RFC has one, and because a document that only contains the sections it needs has quietly told you it was written for the reader's convenience rather than the form's integrity.
12. Acknowledgements #
This section thanked a named colleague for a specific night and thanked readers for corrections. Neither happened. The people were the prototype's and the incident was the same invented one that 7.19 removed from note 3.4, which left this page thanking somebody for an event Section 3 had already withdrawn. It is 7.36, and the section is empty until it is earned.
No reader has yet sent a correction that changed anything here. Every entry in Section 7 so far is the author finding his own error, which is the cheaper kind and the less useful one. The offer stands and the address is in 14: being told you are wrong by someone who read carefully is the fastest form of professional development available, and it is free.
13. References #
13.1. Normative References
| Tag | Reference |
|---|---|
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC1925] | Callon, R., "The Twelve Networking Truths", RFC 1925, April 1996. Truth (3) is load bearing in most architecture reviews I have attended. |
| [RFC8890] | Nottingham, M., "The Internet is for End Users", RFC 8890, August 2020. |
13.2. Informative References
| Tag | Reference |
|---|---|
| [PERROW] | Perrow, C., "Normal Accidents: Living with High-Risk Technologies", 1984. The book that explains why your postmortem keeps finding a root cause that is not one. |
| [COOK] | Cook, R., "How Complex Systems Fail", 1998. Four pages. Read it twice a year. |
| [SCOTT] | Scott, J.C., "Seeing Like a State", 1998. Every argument about data sovereignty is downstream of this, whether or not the people having it know. |
| [CONWAY] | Conway, M., "How Do Committees Invent?", 1968. Your service boundaries are an org chart with better uptime. |
| [NORMAN] | Norman, D., "The Design of Everyday Things", 1988. Applies to APIs more than to doors. |
14. Author's Address #
| Channel | Address |
|---|---|
| Name | Mosthofa Imran |
| Role | CTO |
| Organisation | Betopia Limited |
| Location | Dhaka, Bangladesh (UTC+6). Comfortable overlapping with CET mornings and US Pacific evenings. |
| hey@mosthofaimran.com. I read everything and answer most things inside two working days. | |
| vCard | contact.vcf, generated from the same source as this table. It carries a mobile number, which this table does not: a number in a downloadable card is reachable by anyone who wants it, and a number in the markup is reachable by everyone who scrapes it. |
| Scan | mosthofaimran.com/scan. A QR code carrying the card itself, so a phone can add it with the network off. |
| Code | github.com/johnefemer |
| Résumé | Section 6 |
| Key | /pgp.asc (not yet published: no key exists, see the ledger), fingerprint in 9.3 |
| Feed-ranked platforms | Handles exist so people can reach me. I do not post there, build an audience there, or publish anything there first. Paper 5.3 is the reasoning, and it holds for taking part rather than for holding an account. |
Appendix A. Document History #
The four most recent revisions. All 46 are at Appendix A, complete, which is the record this document is versioned against: the identifier above is the number of entries, less one.
| Date | Change |
|---|---|
| 2026-09-10 | The note on the contact card is written for a card now rather than borrowed from the document, which cited a section number a stranger holding the card cannot resolve. It travels in the QR too, which took the code from 69 modules to 85 and the drawing from 320px to 380 so a module stays the same size. |
| 2026-09-10 | The phone row on the card was still labelled VALUE after 7.49 said it was fixed, because the diagnosis was wrong: that client does not read the VALUE parameter on TEL at all. Plain number now, no URI. Erratum 7.50. |
| 2026-09-10 | The phone row on the contact card was labelled VALUE rather than mobile in a real address book, and two touchpoints both read as home page. The card now labels four. Erratum 7.49. |
| 2026-09-10 | The author is CTO at Betopia Limited. The previous title, Head of Engineering and Delivery, stands in this appendix and in erratum 7.9 rather than being overwritten. Contact gains an organisation and a mobile number, the card gains the properties an address book files it by, and a QR at /scan/ carries it. Erratum 7.47. |
Appendix B. Colophon #
What this is built from, what it weighs and how it is licensed, at Appendix B, complete. It moved off this page for the reason Appendix A did: a colophon is the least urgent thing in a byte budget.
Signature #
Detached signature over the canonical Markdown source of this
document, published at each paper carries one at /papers/<slug>.md.asc.