SIPI / colophon
About SIPI
SIPI is an educational project created and directed by Geetansh Arora. This page explains the authorship, technical review, model evidence, source policy, AI assistance, and the process for reporting a correction.
Report a correction or question
Open an issue at github.com/geetansharora/SIPI/issues. A public issue keeps the discussion and any correction connected to the relevant page.
The following details help reproduce and assess the issue:
- The page and the exact sentence. A scenario link from a panel
(the
linkbutton) is ideal for anything interactive, because it reproduces the state you were looking at. - What you expected instead, and why. A number, a formula, or a source.
- Which kind of claim it is — arithmetic, model behaviour, or a specification statement. The three are corrected differently and the fix routes differently.
Arithmetic and model-behavior corrections can often be checked with the automated gates. Specification questions require the relevant primary source, so they may take longer to resolve.
What counts as a source
Everything on this site is meant to be derivable from public sources — JEDEC, PCI-SIG, USB-IF, MIPI, published papers, or first principles. No employer data, no internal numbers, no unreleased silicon.
The source policy uses three additional rules:
- A vendor application note does not stand in for a specification. Vendor guidance can explain an implementation; it cannot establish what a standard requires.
- An unverified claim is labelled, not quietly asserted. Where a standard is not publicly accessible, the identifier is cited anyway and the claim is recorded as awaiting verification in the claim ledger.
- Arithmetic is not sourcing. A number computed from a formula is
checked by recomputing it, which is a different and stronger thing than citing
somebody. Those numbers live in
check-numbers.py.
How each kind of claim is checked
| Kind of claim | Checked by | What that catches |
|---|---|---|
| A number in the prose | check-numbers.py | a number that disagrees with its own formula, or that drifted when a page was edited |
| Model behaviour | check-models.js | physics: a non-causal filter, a lost echo, a sentinel that reads as “wide open” |
| Page structure | scaffold.py check | dead links, unbalanced tags, a panel whose model contract is missing or stale |
| Whether a gate can fail | mutate.js | a known defect that no assertion detects, and a run that went red for the wrong reason |
| A specification statement | a human, reading the specification | nothing automatic. The ledger records what each source type can establish, and refuses to mark a standard's requirement verified from a press release — but it cannot read the standard for you. This is the weakest link. |
The strongest model assertions are designed to be independent of the code they test. Re-running the same formula in a second file can catch a typo but does not provide an independent check, so the assertions use analytical limits, conservation laws and closed-form special cases instead — and monotonicity only where a precondition is stated, because "more loss never opens an eye" is true for a reflectionless channel and false once a reflection can be damped.
Mutation checks confirm that the relevant assertion detects each recorded defect.
mutate.js holds every known defect this project has shipped, applies one at a
time to an isolated copy of the tree, and requires the assertion that claims to catch
it to be the one that fails — a syntax error or an unrelated failure counts as a
harness error, not as detection. It exists because the model gate once reached 276 passing
assertions while a 6 dB error in the equaliser's applied gain went unnoticed by all
fourteen of its equaliser assertions, one of which compared a quantity to itself. An
assertion count is not a quality measure. node mutate.js --selftest checks the
harness the same way, by requiring a behaviour-preserving edit to be reported as
surviving.
What each individual model assumes, and how well it has been checked, is published at model contracts.
What is not established is stated as plainly as what is. The gaps that remain are human rather than computational: sessions on a physical phone and with a screen reader, short observed learner tasks, and a small number of specification claims still waiting on a primary source. The claim ledger marks those individually, and no model page claims evidence it does not have.
Creator and technical review
Geetansh Arora, Principal SI/PI Engineer, is the creator, project lead, editorial director, and principal technical reviewer. On 14 September 2026 he completed a technical read of every currently published page and explored the labs hands-on. That review covers the educational content as published on that date; it does not independently validate every numerical result, standards requirement, or use outside the stated model limits.
Automated gates complement that review by checking arithmetic, structural invariants, model limits, and known regression cases. They do not establish standards compliance, measurement correlation, behavior outside the stated model range, or suitability for sign-off.
Development and AI assistance
Plain HTML, CSS and JavaScript. No framework, no build step, no dependencies. Every visualisation is hand-written Canvas or inline SVG, and the maths is hand-set rather than rendered by a library. You can read any page's source and see everything it does.
Created and directed by Geetansh Arora, with technical review and hands-on lab exploration by him. Developed with assistance from Claude Opus and OpenAI Codex models Astra and Sol. These tools supported drafting, implementation, testing, and editorial work; they do not provide independent human judgement or endorsement by Anthropic or OpenAI. Responsibility for the published project remains with Geetansh.
Source: github.com/geetansharora/SIPI. Prose and diagrams are CC BY 4.0; the code is MIT. See LICENSE-CONTENT and LICENSE-CODE.
Change log
Substantive changes — corrections, new models, changed claims — are recorded in CHANGELOG.md. The full history is in the repository; the changelog is the subset that would change what a reader believes.