# Brendan A R Sechter's Development Blog A personal technical notebook covering systems programming, systems philosophy, tooling, mathematics, and emerging software paradigms. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Keleusma Research Spike: What Happens When Error Correction Meets a Signature DevFeed: [Keleusma Research Spike: What Happens When Error Correction Meets a Signature]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-10T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Security, Privacy and Abuse Prevention](), [Cryptography](), [Code](), [Compiler]() Tags: [bytecode](), [compiler](), [compilers](), [cryptographic](), [engineering](), [integrity](), [research](), [security](), [test](), [verification]() ### AI overview This case study examines how combining error correction with cryptographic signatures can create an unsafe verification order. Exhaustive analysis of bit errors shows that some damaged inputs are incorrectly repaired or reported as clean, so a clean correction result does not establish integrity. ### Source excerpt A file carries an error-correcting code so that a flipped bit can be repaired, and a cryptographic signature so that a changed byte is refused. Both are ordinary. Putting them in the same file forces a choice that neither feature announces, and one of the two answers is sound only under an assumption that the error-correcting code exists because it is false. The uncomfortable part is that the two answers are indistinguishable on every input anybody tests. An undamaged file behaves identically under both. They diverge only on damaged input, and damaged input is the case the error-correcting code exists for and the case no test suite exercises, because producing it requires deliberately corrupting your own artefact. Enumerating the fault space of a single 64-bit word exhaustively, rather than sampling it, gives four numbers that decide the design. The space is small enough to enumerate because the number of ways to flip $w$ bits out of 64 is a binomial coefficient, and for $w \le 4$ it stays under a million. \[\binom{64}{1} = 64, \quad \binom{64}{2} = 2{,}016, \quad \binom{64}{3} = 41{,}664, \quad \binom{64}{4} = 635{,}376\] flipped bits patterns repaired exactly wrongly "repaired" invisible 1 64 64 0 0 2 2,016 0 0 0 3 41,664 0 23,364 (56.08%) 0 4 635,376 0 0 5,133 (0.81%) Three flipped bits are reported as a successful repair 56.08 percent of the time, and the repair is wrong every time it happens. Four flipped bits are, 5,133 times, completely invisible, because the code reports the word as clean when the error pattern is itself a valid codeword. The consequence is one sentence, and everything else in this article is either its derivation or its implications. The corrector is not an authority on whether it corrected, and a clean report from it is not evidence of integrity. What this is a case study of The setting is the bytecode format for Keleusma, a language whose value proposition is that a program's worst-case time and memory can be proven before it runs, and wh ## Keleusma Research Spike: What It Costs to Compile a Data Structure Whose Shape Is Already Decided DevFeed: [Keleusma Research Spike: What It Costs to Compile a Data Structure Whose Shape Is Already Decided]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-09T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [Back end](), [Data structures]() Tags: [arrays](), [case-study](), [compiler](), [compilers](), [data-structure](), [engineering](), [research](), [verification]() ### AI overview This case study examines the cost of compiling aggregate data types in the Keleusma compiler backend. Measurements of 331 aggregate operations found that most reduce to constant offsets and typed loads, challenging an estimate based on the feature's general name rather than its actual instances. ### Source excerpt The largest remaining item in a compiler backend was estimated at a quarter's work. Measured, it is pointer arithmetic over compile-time constants, and two of the three representation forms it was supposed to need account for two operations in the entire corpus. The item is aggregate data types, meaning structs, tuples, arrays and enumerations. It blocks 34.5 percent of the corpus, more than every other unimplemented feature combined, and it had never been scoped because everyone knew it was large. Everyone was reasoning from the wrong artefact. Aggregates are large in a compiler that must decide their layout. This compiler decided it already, in an earlier pass, and bakes the answer into the instruction stream. What reaches the backend is not a type system. It is a byte offset and a scalar kind. The measurement that establishes this took twenty minutes to write and two and a half seconds to run. It reports that of 331 aggregate operations in the corpus, 300 are a constant offset and a typed load, 2 need anything resembling a value representation, and 0 use the general mechanism the instruction set still carries. This article reports that, and reports why the author's own recommendation to run it deserves more scepticism than the result. What this is a case study of The setting is compiler backend scoping and the project is Keleusma, whose backend is described in the first, second and third articles of this series. No compiler background is required. The general shape is estimating the cost of a feature from its name rather than from its instances. "Aggregate data types" names something with a large literature, a hard general case, and a well-known set of representation decisions. None of that is evidence about the work in front of you, and the gap between the category and the instance is where the estimate went wrong. The transferable question is what remains once a decision has already been made upstream. The answer is often mechanical, and the mechanical residue ## Do Verified Memory Bounds Survive Compilation? DevFeed: [Do Verified Memory Bounds Survive Compilation?]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-08T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler]() Tags: [compiler](), [compilers](), [engineering](), [verification]() ### AI overview This case study examines whether a verified memory bound remains applicable after compilation. An erratum corrects earlier measurements: on the measured corpus and shipped pipeline, the proven bound was empirically conservative, but this does not establish soundness because the bound and compiled frame measure different quantities. ### Source excerpt Erratum, 2026-08-12 The empirical sections of this article measured code that had never been optimised, and the corrected figures reverse the direction of the finding. The measurement invoked the back end at two optimisation levels over the same intermediate representation. The pass that promotes stack slots into registers is a middle-end pass and the back end does not run it, so both figures described unpromoted code and the difference between them was back-end noise. Three claims made below are wrong and are corrected in place, with the original figures retained so the change is visible. The optimiser eliminates the provisioning, and does not relocate it into spill slots. Promoted then lowered, the same 19 modules occupy 5,048 bytes of frame against the 275,432 bytes reported here for unpromoted code, a factor of 54. The proven bound exceeds the real frame in every module measured, rather than falling short of it. The ratios run from 0.12 to 0.88. The article's claim that this fails in the dangerous direction is the reverse of what happens. The provisioning change reported elsewhere as a large saving buys nothing for the shipped pipeline, since promotion had already removed the dead allocations. This does not rescue the bound. Eight modules agree that it exceeds the frame and no mechanism guarantees that. The two quantities are in different units, count different things and are decided by different agents, so the agreement is coincidence and not construction. The supportable statement is that the bound is empirically conservative on this corpus under the shipped pipeline, which is much weaker than sound. The structural contribution is unaffected, being the three-part split of the bound set out in Result 1, the literature survey, and the timing result with its stated weakness. Somebody proves a program can never use more than a certain amount of memory. Then a compiler rewrites that program into a different form before it runs. Does the proof still apply? The answe ## Why Two Similar Compiler Cases Cannot Share One Calling Convention DevFeed: [Why Two Similar Compiler Cases Cannot Share One Calling Convention]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-07T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [interface](), [Back end](), [test](), [Mathematics]() Tags: [article](), [backend](), [case-study](), [class](), [compiler](), [compilers](), [engineering](), [interface](), [mathematics](), [measurement](), [verification]() ### AI overview This compiler backend case study argues that two similar cases cannot be unified when one must report two values through an interface with only one available slot. A counting argument shows that the apparent similarity of nine measured occurrences is irrelevant to the shared interface design. The article also identifies an earlier rule that unnecessarily excluded ten of twenty-four cases. ### Source excerpt A system had grown two ways of doing what looked like one thing. The obvious move was to tidy them into one. The tidying turns out to be impossible, and the reason it is impossible is the reason the two ways exist. The argument that settles it needs no specialist knowledge and fits in a sentence. One of the two cases has two things to report and only one slot to report them in. Whichever thing the slot is given, the other is lost. The other case has only one thing to report, so the single slot is exactly enough. That is a counting argument, it is decided before any code is written, and it is not the argument an engineer reaches for by default. The engineer's instinct is to look at the cases and ask whether they resemble one another. They did. Every one of the nine measured occurrences had exactly the shape that invited the tidy-up, and the measurement encouraged precisely the wrong conclusion. The resemblance was real and it was irrelevant, because the defect was never in the instances. It was in the interface they would have had to share. This article is about that distinction, which is between evidence about members of a class and evidence about the channel the class must pass through. The second dominates the first and is cheaper to check. The article reports the measurement, the way the measurement pointed the wrong direction, and the argument that settled it. It also reports a rule this author shipped one increment earlier which turns out to be stricter than the property it enforces, excluding ten of twenty-four cases for no reason. No test found that. It surfaced while gathering data for this article. How to read this The general argument is in the opening, in the section called The Argument That Settled It, and in Pattern Extraction. Those three need nothing but attention. The sections between them work the argument through a real case with real numbers, and they use the vocabulary of the trade. Every term is glossed at first use, but a reader who wants the r ## Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage DevFeed: [Keleusma Research Spike: Blocking Frequency as the Ordering Principle for Instruction-Set Coverage]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-06T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Compiler](), [Code generation](), [Code]() Tags: [article](), [code-generation](), [compiler](), [compilers](), [engineering](), [measurement](), [ordering](), [research](), [verification]() ### AI overview This case study examines how blocking frequency can guide the order of instruction implementation in Keleusma's compiler backend. It contrasts instruction-level coverage with whole-program compilability and describes a small measurement tool that exposed a flawed implementation plan. ### Source excerpt A compiler was 87 percent finished. It could not compile two thirds of the programs it was for. Both numbers are correct. The first counts individual instructions the compiler knew how to translate. The second counts whole programs that would actually go through. The gap between them is what this article is about, and the reason it exists is simple enough to state in one sentence. A program needs every instruction it uses, not most of them. One missing instruction out of a hundred stops the whole thing, exactly as one missing link stops a chain. That gap then destroyed a carefully reasoned plan. One working session before the measurement was taken, the author of this article had formally recommended what the next piece of work should be. The reasoning had no invalid step in it. The measurement showed the recommendation to be worth nothing at all, because the thing it would have unblocked does not occur even once in any program the compiler is meant to serve. The instrument that established this took about twenty minutes to build and two seconds to run. The article reports that, and then reports four errors made while writing it, all four of which ran in the direction of a more striking result, and one of which was committed inside the paragraph warning against the other three. What this is a case study of The setting is compiler engineering, and a reader who has never written a compiler can follow the argument, because the shape of the problem is not specific to compilers. The concrete project is Keleusma, whose compiler until now has emitted bytecode for a virtual machine, as described in the self-hosting strategy and its getting-started article. Native code generation is the step after that one, and it is where the ordering question first became expensive enough to measure. The lineage of the design sits in the stream-based compilers series and in the self-hosted silicon compiler. None of that background is needed to follow what follows, and the measurement stands ## History of SpaceX: Synthesis, the Independence Assumption, and Projection through 2050 DevFeed: [History of SpaceX: Synthesis, the Independence Assumption, and Projection through 2050]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-05T09:00:00Z Content type: opinion Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [Framework]() Tags: [aerospace](), [analysis](), [business](), [framework](), [history](), [open-questions](), [projection]() ### AI overview This concluding article in a History of SpaceX series retrospectively assesses the series' framework, argues that its supposedly separable conditions are coupled, and examines how that independence assumption affects assessment. It also projects the analysis to 2050 under stated assumptions, ranks failure modes, and identifies unresolved questions. ### Source excerpt This article closes the History of SpaceX series. It has three tasks. The first is retrospective, restating the seven forcing-function conditions and the three capital-formation legs that the series opener introduced and that the intervening ten articles developed, and assessing what each turned out to establish. The second is critical, and it is the article's principal contribution. Across three independent articles the series encountered the same structural surprise, namely that conditions the framework treats as separable are in fact coupled, and the closing article argues that the coupling is general and not incidental and that the framework's independence assumption biases the assessment in opposite directions depending on the state of the world. The third is projective, extending the analysis to 2050 under explicitly stated assumptions and with the failure modes ranked, not merely listed. The article treats the alternative contemporary configurations that the commentary offers as templates, comprising the defense-technology venture, the failed-governance case, the intelligence-anchor case, and the patient-single-funder case, and the deep historical precedents comprising the industrial consolidation, the corporate research laboratory, the endowed foundation, the mass-production firm, and the early aircraft manufacturers. The article closes with the load-bearing open questions the series as a whole leaves unresolved, which are more numerous than any single article's closing section suggested. The Synthesis Problem The mapping problem for a closing article differs from that of the eleven that precede it. Those articles each asked what happened along one dimension. This one asks whether the dimensions were the right ones, whether the framework built from them holds together, and what it predicts. The series advanced a thesis, which the series opener states as the singular-conjunction claim. The claim is that a particular venture is the only modern case satisfying ## History of SpaceX: The Category-Dominating Commercial Spinoff and the Internalization of Anchor Demand DevFeed: [History of SpaceX: The Category-Dominating Commercial Spinoff and the Internalization of Anchor Demand]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-04T09:00:00Z Content type: article Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [communications](), [Deployment](), [service]() Tags: [aerospace](), [beta](), [business](), [capacity](), [customer](), [deployment](), [history](), [international](), [launches](), [operational](), [partnership](), [regulatory](), [revenue](), [service](), [spacex](), [subscriber]() ### AI overview This article examines SpaceX's commercial spinoff as the internalization of an anchor customer. It explains how the spinoff consumes the parent's launch output at marginal cost, traces its deployment, service rollout, integration, subscriber and revenue development, direct-to-cell expansion, capital requirements, and regulation, and compares the configuration with other satellite-constellation businesses. ### Source excerpt This article is the eleventh in the History of SpaceX series and the third and last treating the capital-formation legs that the series opener introduced. The category-dominating commercial spinoff concerns the business the venture built on top of its own capability, and the article's organizing claim is that the spinoff is not a diversification into an adjacent market but the internalization of an anchor customer. Where the Anchor Demand article A283 treats a government customer buying launches, this article treats the venture becoming the customer it had previously needed someone else to be. The decisive economic property is not that the spinoff grew large. It is that the spinoff consumes the parent's output at marginal cost while every competitor attempting the same business must pay a market price the parent sets. The article walks the January 2015 announcement and the capacity argument that motivated it, the deployment sequence from the first operational batch of May 2019 through the service beta of 2020 and the commercial rollout of 2021, the vertical integration and the internal transfer price that the whole arrangement turns upon, the coupling between constellation deployment and launch cadence, the subscriber and revenue trajectory across the 2020 through drafting-date period, the direct-to-cell extension beginning with the carrier partnership announced in 2022, the capital intensity and the replenishment obligation that a short-lifetime constellation imposes, and the regulatory position across the Federal Communications Commission, the International Telecommunication Union, and the national regulators whose authorizations the service requires. The article contrasts the configuration against the Iridium and Globalstar precedents, in which comparable constellations were built without a captive launch capability, and against the OneWeb and Kuiper cases, in which competitors attempted the business while buying launch at market. The article closes with an expli ## History of SpaceX: The Patient-Private Capital-Formation Leg and the Manufacture of Patience DevFeed: [History of SpaceX: The Patient-Private Capital-Formation Leg and the Manufacture of Patience]() Original publisher: [Read original article]() Author: Brendan Sechter Published: 2026-08-03T09:00:00Z Content type: opinion Language: en Sources: [Brendan A R Sechter's Development Blog]() Topics: [structure](), [Google](), [Development]() Tags: [aerospace](), [article](), [business](), [company](), [google](), [history]() ### AI overview This analytical article examines how private-capital instruments financed SpaceX's development despite venture-fund time constraints. It focuses on investor entries, funding rounds, tender offers that provided liquidity without an exit, investor time horizons, and dilution management, while comparing the structure with Iridium and OneWeb. ### Source excerpt This article is the tenth in the History of SpaceX series and the second of three treating the capital-formation legs that the series opener introduced. The patient-private leg concerns the private capital that financed the development the government leg did not, on terms that surrendered equity and did not surrender the mission. The article's organizing claim is that patience is not a temperament that investors possess but a structural property that instruments manufacture, and that the instruments are identifiable, describable, and largely absent from the commentary that attributes the outcome to investor conviction. The binding constraint on private capital in the venture form is the fund-life clock, which obliges a fund to return capital to its limited partners on a schedule that has no relation to the development horizon of any portfolio company. The article walks the fund-life constraint and the duration mismatch it creates, the August 2008 Founders Fund entry at the moment of maximum distress, the 2009 Draper Fisher Jurvetson entry, the January 2015 Google and Fidelity round motivated by a business line that did not yet exist, the round and valuation sequence across the 2015 through drafting-date period, the semi-annual tender-offer mechanism that gives liquidity without exit and that the article treats as the decisive structural innovation, the composition of the investor base and the horizon heterogeneity across it, and the dilution management that preserved the control configuration the Governance article A287 analyzes. The article contrasts the configuration against the Iridium capital structure, in which a debt-financed constellation faced a fixed obligation schedule that no development delay could accommodate, and against the OneWeb funding withdrawal, in which a nominally patient investor proved otherwise. The article treats the contemporary defense-technology venture wave and the Anduril and Palantir comparisons as the downstream consequence. The arti