About the author and publication

Responsibility

Steven Geller is a CTO with two decades of experience building and securing infrastructure, primarily in financial systems. His current technical work includes cryptographic systems and post-quantum migration.

Steven Geller writes and maintains this field guide. The named author is the accountable editor for its explanations, structure, source choices, and corrections.

The author profile describes relevant engineering experience; it does not claim an academic appointment, physics doctorate, or independent peer-review credential.

Scope

The book is written for computer scientists and engineers who want the full system: mathematics, circuits, algorithms, software, fault tolerance, hardware, applications, and diligence. It is educational material, not investment advice and not a substitute for safety, legal, or security review.

How to read trust signals

Each chapter names its author, dates, and sources. When nobody outside the project has signed off, the page simply says “Open.” Polish is not proof.

Main site biography · GitHub · LinkedIn

Privacy and first-party measurement

This publication uses cookieless, first-party measurement to learn whether readers can find and finish useful material. Events include the canonical pathname, page type, chapter and part labels, coarse viewport and referrer classes, reading milestones, navigation and citation actions, artifact and audio use, search result counts, and basic loading, interaction, and layout performance.

The client does not send URL query strings, raw book-search text, article text, email addresses, or a cross-site identifier, and it does not set an analytics cookie. Search activity is reduced to a query-length range and result count. Do Not Track is honored: when the browser sends that preference, the client sends no measurement events.

Measurement is posted to this site's own /.sg/event endpoint. It is used to improve the publication's content, navigation, accessibility, and performance—not to build advertising profiles.

Editorial standard

Explanations are expected to connect the abstraction to a calculation, an implementation or system constraint, and the limits of the claim. A smooth paragraph is not evidence. A citation is not decoration. A benchmark is incomplete until its task, baseline, metric, assumptions, and date are visible.

Source hierarchy

1. Primary literature and standards. Papers, standards, specifications, official technical reports, and reproducible datasets carry the most weight for factual claims.
2. Authoritative synthesis. Textbooks and serious lecture notes provide stable framing and derivations.
3. Vendor material. Useful for describing a vendor's own architecture or claim, but labeled and checked against independent evidence where possible.
4. Secondary reporting. Used for context, not as the sole support for a technical conclusion when a primary source exists.

What the labels mean

Named author

Steven Geller is responsible for the published work and its corrections. That is not a substitute for an outside expert.

Outside review

A reviewer is named only after a verifiable record exists. Until then, the chapter says “Open.”

Source mapping

Each chapter has a registered source list, and rewritten chapters map their load-bearing claims to those sources inline. A reference supports only the bounded claim beside it; proximity does not transfer authority to unrelated claims.

When prose feels machine-made

No single word proves how a passage was written. The giveaway is usually a pattern: every section moves in the same rhythm, transitions keep returning, and confident claims arrive without a calculation, source, measurement, or named limit.

We edit for the reader, not for an authorship detector. Each chapter gets the shape its subject needs. Important claims must lead to something a reader can inspect: a derivation, a runnable test, a measured constraint, or a primary source. If a paragraph would still work after swapping in another chapter's topic, it is not specific enough.

Dates and changing claims

datePublished records the publication date in the chapter manifest. dateModified changes only when the chapter or its publication record is materially revised; a routine build does not create a freshness date. Claims about companies, benchmarks, markets, or current systems must state their time boundary in the prose.

Automation and authorship

Generative tools helped with research routing, drafting, rewriting, code, copy editing, and automated checks during the 2026 rebuild. Steven Geller remains responsible for every published claim. Tool output is never treated as evidence or sign-off.

No generated citation, credential, reviewer, experimental result, or claim is accepted merely because a system produced it.

Corrections

Corrections are separated from general release notes so a reader can see what was wrong, what changed, and which chapters are affected. See the errata process and publication changelog.