REF 001 / CONTROL SYSTEMS
Feedback loop
A feedback system measures some aspect of its output or state, compares that measurement with a desired condition, and uses the difference to influence future behavior. Thermostats, motor controllers, autopilots, biological regulation, and many organizational processes all use versions of this pattern.
The important detail is delay. A controller acts on information about a system that may already be changing. Too much correction, too late, can create oscillation. Too little correction can leave persistent error. Useful control therefore depends on measurement quality, response speed, system dynamics, and what happens when sensors lie or disappear.
Failure question: what does the controller do when the measurement remains plausible but wrong?
Read the feedback-control briefing →
REF 002 / ENGINEERING
Graceful degradation
A system degrades gracefully when a component failure reduces capability without immediately destroying the entire mission. The opposite is a brittle architecture where one local fault cascades into total loss.
Graceful degradation can come from redundancy, safe default states, reduced-performance modes, mechanical stops, independent protection circuits, fallback communications, or simply designing the system so failure is legible before it becomes catastrophic. Redundancy is not automatically graceful if all redundant paths share the same hidden dependency.
Design question: after the first failure, what useful capability remains?
Read the resilience field guide →
REF 003 / INFORMATION INTEGRITY
Checksum versus cryptographic hash
Both are compact values derived from data, but they are built for different jobs. A simple checksum is mainly useful for detecting accidental corruption. A cryptographic hash is designed so that finding a different input with the same output, or reconstructing the original input from the hash, is computationally difficult for a well-designed modern function.
That distinction matters when evidence or software integrity is at stake. A checksum can tell you that bits probably changed in transit. A cryptographic hash can support a much stronger integrity workflow, especially when the expected hash itself comes from a trusted source.
Failure question: who supplied the reference value you are trusting?
Read the deeper integrity guide →
REF 004 / AI + MEASUREMENT
Calibration
Calibration asks whether stated confidence matches observed reliability. If a system labels many predictions as roughly 80% confident, a well-calibrated system should be correct on something close to 80% of those cases over an appropriate sample.
Calibration is different from accuracy. A highly accurate model can still be poorly calibrated if it is systematically overconfident or underconfident. For reasoning systems, the challenge is messier because confidence may be expressed through language rather than a clean numeric probability.
Evaluation question: when the system sounds certain, how often has that certainty historically been justified?
Read the calibration field guide →
REF 005 / EVIDENCE
Provenance
Provenance is the recorded origin and history of an item of information, object, dataset, image, measurement, or claim. It answers questions such as where this came from, when it was created, who handled it, what transformations occurred, and which version is being discussed.
Provenance does not prove that a claim is true. It makes the claim auditable. A perfectly documented bad measurement is still a bad measurement, but at least another person can locate the problem instead of inheriting an orphaned conclusion.
Verification question: can another person reconstruct the path from source to present claim?
Read the provenance archive file →
REF 006 / CYBERNETICS
Myoelectric control
Myoelectric control uses electrical activity associated with muscle activation as an input to a device, often a prosthetic or assistive system. Surface electrodes can detect voltage changes at the skin that correlate with underlying muscle activity, after which signal processing and control logic map those patterns to commands.
The hard part is not merely detecting a signal. Electrode placement, skin contact, fatigue, sweat, limb position, motion artifacts, changing muscle recruitment, and user learning can all affect performance. A useful system therefore has to tolerate biological variability rather than assuming the input behaves like a laboratory switch.
Design question: how does the controller behave when yesterday's clean signal becomes today's noisy one?
Read the myoelectric-control briefing →
REF 007 / SOFTWARE + DIAGNOSTICS
Observability
Observability is the ability to infer enough about a system's internal behavior from the evidence it exposes. In software that evidence may be logs, metrics, traces, health checks, request IDs, queue depth, latency, saturation, or error rates. In physical systems it may be current, temperature, vibration, pressure, diagnostic codes, or test points.
More telemetry is not automatically more observability. A thousand counters that cannot distinguish competing failure explanations are decoration with storage costs. Useful instrumentation should help answer what changed, where the failure propagated, which dependency participated, and whether recovery actually worked.
Failure question: can somebody who was not present reconstruct the event?
Read the observability briefing →
REF 008 / SCIENTIFIC METHOD
Measurement versus inference
A measurement is the result produced by an observation process or instrument under defined conditions. An inference is a conclusion drawn from that result using assumptions, models, calibration, context, or prior information. The two can be tightly connected without being identical.
A gravitational-wave detector records an instrument response that can be represented as strain. Source masses, spins, distance, and sky position are inferred by comparing the measured signal with physical models and detector behavior. Similar layers appear almost everywhere: sensor voltage versus temperature, pixel intensity versus object classification, packet timing versus network diagnosis.
Method question: what did the instrument directly report, and what did the model add afterward?
See the distinction in gravitational-wave detection →
REF 009 / MEASUREMENT + DECISIONS
Uncertainty budget
An uncertainty budget lists meaningful sources of uncertainty in a result and estimates how much each source contributes. The goal is not to decorate a number with error bars. It is to understand where confidence is being lost and which improvement would actually matter.
Sources can include instrument calibration, resolution, environmental variation, sampling, model assumptions, geometry, timing, operator effects, data processing, or unknown correlations between terms. Combining them correctly depends on the measurement model and on whether the uncertainties are independent, correlated, random, or systematic.
Decision question: which uncertainty is large enough to change the conclusion or the next action?
Read the uncertainty field note →
REF 010 / EMBEDDED SYSTEMS
Watchdog timer
A watchdog timer is an independent timing mechanism used to detect when software has stopped making expected progress. Healthy software periodically services or “kicks” the watchdog. If that does not happen before the timeout, the watchdog can trigger a reset, interrupt, safe-state transition, or other recovery action.
The useful part is independence. A watchdog implemented entirely inside the same failed task may fail with it. Hardware watchdogs or sufficiently isolated supervisors can recover from hangs, deadlocks, runaway control flow, or other failures that leave the main software unable to rescue itself.
Failure question: what condition proves the system is healthy enough to service the watchdog, rather than merely still executing instructions?
Read the watchdog recovery guide →
REF 011 / SECURITY LITERACY
Threat model
A threat model is a structured description of what needs protection, who or what might threaten it, which attack surfaces exist, what assumptions the design relies on, and which mitigations are worth the cost. It keeps security tied to a real system instead of an infinite list of frightening possibilities.
Useful threat modeling begins with assets and trust boundaries. Identify data, credentials, physical capabilities, privileged actions, external dependencies, users, administrators, and places where information or authority crosses from one zone to another. Then ask what an attacker could realistically gain, alter, deny, impersonate, or observe.
Security question: which single assumption, if false, exposes the most important asset?
Open Software Operations →
REF 012 / ASTROPHYSICS + ORBITAL MECHANICS
Specific orbital energy
For an ideal two-body gravitational problem, specific orbital mechanical energy is the total orbital energy per unit mass:
ε = v²/2 − μ/r
Here v is relative speed, r is distance from the central body's center, and μ = GM is the standard gravitational parameter. Negative ε corresponds to a bound Keplerian orbit, zero to the parabolic escape boundary, and positive ε to an unbound hyperbolic trajectory.
The equation is powerful because it connects local speed and position to the overall orbit. It is also an approximation. Perturbations, non-spherical gravity, drag, thrust, third bodies, relativistic effects, and rotating reference frames can matter depending on the mission and required precision.
Model question: which neglected force becomes large enough that the two-body approximation stops answering the mission question?
Read the orbital-energy field guide →
REF 013 / EMBEDDED POWER
Brownout reset
Brownout reset is a hardware mechanism that forces a processor into reset when supply voltage falls below a defined threshold. The objective is to stop execution before voltage enters a region where CPU timing, flash access, peripherals, or logic thresholds are no longer guaranteed.
A useful implementation also considers hysteresis, response time, rail sequencing, and when reset may safely be released again. The threshold must protect the system that actually exists, not merely the processor core in isolation. External memory or peripherals can become unreliable before the MCU itself.
Failure question: does reset assert before any critical device leaves its guaranteed operating range?
Read the brownout field guide →
REF 014 / SIGNAL INTEGRITY
Common-impedance coupling
Common-impedance coupling occurs when two circuits share part of a conductive path and current from one circuit creates a voltage across the shared impedance that appears in the other circuit's reference or signal path.
The mechanism can be summarized by V = I × Z. If a motor, radio, converter, or digital load changes current through a conductor that a sensitive sensor also uses as its reference, the sensitive circuit sees the resulting voltage even though the schematic may label the whole conductor “ground.”
Layout question: which unrelated currents share copper, vias, connectors, cable conductors, or plane regions?
Read the grounding field guide →
REF 015 / ELECTROMAGNETIC COMPATIBILITY
EMI coupling path
An electromagnetic-interference problem requires a source, a victim, and a path that transfers unwanted energy between them. The path may be conductive, capacitive, inductive, common-mode, or radiated, and several mechanisms can operate at once.
This framing is more useful than treating EMI as a substance floating around the board. Reduce the source, interrupt or redirect the path, harden the victim, or combine all three. Geometry, edge rate, loop area, reference continuity, cable common-mode current, shielding, and filter placement all matter because they change the coupling mechanism.
Diagnostic question: what physical path lets energy from this source reach this victim?
Read the EMI field guide →
REF 016 / EMBEDDED RESILIENCE
Windowed watchdog
A windowed watchdog constrains not only how late a watchdog refresh may occur, but also how early. Servicing the watchdog outside the allowed time window is treated as a fault.
The early boundary helps detect failure modes where corrupted control flow or a runaway loop reaches the watchdog service point far more frequently than legitimate execution should. It makes the liveness contract harder to satisfy accidentally, but it still does not prove the whole application is healthy. The refresh should remain tied to meaningful system progress.
Design question: can broken software refresh the watchdog at a timing pattern that healthy software could never produce?
Read the watchdog recovery guide →
REF 017 / ASTROPHYSICS + RADIO
Doppler drift
Doppler drift is the change of observed frequency over time caused by changing relative radial motion between transmitter and receiver, along with any intrinsic transmitter or receiver frequency behavior.
For non-relativistic intuition, radial velocity produces a fractional frequency shift approximately proportional to v/c. A changing radial velocity therefore produces frequency drift. Earth rotation, Earth's orbit, spacecraft motion, transmitter dynamics, receiver clocks, and propagation effects can all contribute. In SETI work, drift is evidence about geometry and kinematics before it is evidence about origin.
Inference question: which known motions and instrumental effects can reproduce the observed frequency-time track?
Read the Doppler-drift field guide →
REF 018 / EMBEDDED BUS SYSTEMS
I²C rise time
I²C uses open-drain or open-collector behavior: devices normally pull SDA and SCL low or release them, while pull-up resistors restore the high state. The transition to logic-high is therefore governed by the pull-up network and total bus capacitance rather than an actively driven edge.
Increasing resistance or capacitance slows the rising edge. Too weak a pull-up can violate timing; too strong a pull-up increases sink current and may violate low-level specifications. Harness length, connectors, translators, probes, and every attached device contribute to the electrical bus seen by the controller.
Measurement question: do SDA and SCL actually cross valid thresholds inside the timing budget under the worst real topology?
Read the I²C field guide →
REF 019 / EMBEDDED NETWORKS
CAN fault confinement
Controller Area Network implementations track communication errors and use those counters to limit how strongly a persistently faulty node can affect the bus. Nodes can progress through error-active and error-passive behavior and, after sufficiently severe transmit-error accumulation, enter bus-off.
Bus-off is useful precisely because it is an explicit failure state: the controller stops normal transmission rather than endlessly corrupting shared traffic. The surrounding application still needs a policy for logging, degraded operation, testing, and safe re-entry.
Diagnostic question: which error counter is rising, and what physical or timing mechanism would make that participant accumulate those errors?
Read the CAN field guide →
REF 020 / FIRMWARE RESILIENCE
Boot confirmation and rollback
A resilient update system can treat newly installed firmware as provisional. The candidate boots, performs enough self-test and real startup work to establish basic health, then confirms itself. If it crashes, resets repeatedly, or never reaches the confirmation condition, the bootloader can return to a previous known-good image.
This turns successful programming into only one step of deployment. Persistent-data migration, image signatures, version policy, power-fail behavior, and the independence of the recovery channel all determine whether rollback actually restores a usable device.
Recovery question: what observable condition proves the candidate is healthy enough to become permanent?
Read the bootloader field guide →
REF 021 / THERMAL SYSTEMS
Thermal derating
Thermal derating deliberately reduces electrical or mechanical stress as temperature approaches a region where reliability, performance, lifetime, or safety margin becomes unacceptable. The objective is to preserve useful capability before an emergency shutdown or hardware limit becomes the only protective action.
For semiconductor intuition, junction temperature can often be approximated by Tj ≈ Ta + P × θJA under the assumptions behind the specified thermal metric. Real boards alter that path through copper, vias, heatsinks, airflow, enclosure geometry, neighboring heat sources, and transient thermal mass.
Control question: which commanded capability should decrease first as thermal headroom disappears?
Read the thermal field guide →
REF 022 / PUBLIC RECORDS + CHRONOLOGY
Timestamp provenance
A timestamp is meaningful only when the event and clock that produced it are identified. Document date, recordkeeping date, filesystem creation or modification time, digitization time, server receipt, release publication time, and archive retrieval time can all be valid while referring to different events.
Chronology work should preserve the original value, timezone or clock basis, source field, event type, normalization steps, and known uncertainty. Formatting precision does not prove clock accuracy, and a cryptographic hash can stabilize the identity of the file without making the timestamps inside it historically correct.
Evidence question: what event does this timestamp claim to date, and which system's clock made that claim?
Read the timestamp method guide →