Computing¶
Software engineering¶
Rules found in this domain: P55, P23, P10.
Illustrative, not evidence.
Scenario. A team builds a billing service. It runs linting on each commit, unit tests on each pull request, and integration tests before release. Early on, it also had to choose between a message queue and direct calls.
- P55: Each check runs at the first stage where it can run. A type error is caught by the type checker on commit, not in the integration tests days later.
- P23: The team picks the simplest design that meets the requirements, and splits the service into modules. Each module has one stated purpose, and unused code is removed.
- P10: The choice of direct calls over a message queue is written down with its reason and the rejected alternative, so a later engineer can see why.
Security engineering¶
Rules found in this domain: P36, P40.
Illustrative, not evidence.
Scenario. A company runs a customer database. A batch job only needs to read one table. The database also sits behind a firewall, an access gateway and audit logging.
- P36: The batch job gets read access to that one table and nothing else. A review removes any role holding a permission that was unused for a set period.
- P40: The database has at least two independent control layers, such as the gateway and the audit logging, and each layer is tested. A breach of the firewall alone does not expose the data.
Site reliability engineering¶
Rules found in this domain: P80, P70.
Illustrative, not evidence.
Scenario. An online shop has an outage after a bad deploy. Users see slow checkout pages for an hour, and the team first hears of it from customer complaints. The team writes up the incident afterwards.
- P80: The postmortem looks for the root cause in the system, such as a missing deploy check, and not for a person to blame. It ends in system-level actions.
- P70: Learning about the outage from users is the rule's violation. A postmortem action adds dashboards and alerts for what users feel, checkout latency and error rate, so the next slow deploy pages the on-call engineer within minutes.
Simulation and computational engineering¶
Rules found in this domain: P12.
Illustrative, not evidence.
Scenario. A team uses a flow simulation to size a cooling fan. The model was validated against wind-tunnel tests at low air speeds. Someone wants to use it at much higher speeds.
- P12: The model states its validated range, which is the low air speeds tested. The team uses it only inside that range and checks each result against an independent order-of-magnitude estimate. The high-speed case lies outside the range, so it needs new validation first.
Data and ML engineering¶
Rules found in this domain: P77.
Illustrative, not evidence.
Scenario. A company runs a model that predicts delivery times. After a new customer segment joins, the input data changes and the predictions get worse.
- P77: The data and the model have versions, the inputs are validated, and drift is monitored with an alert. When the alert fires, the team re-evaluates and retrains the model.
Quantum engineering and computing theory¶
Rules found in this domain: P45.
Illustrative, not evidence.
Scenario. A team builds a quantum processor. A single physical qubit is too error-prone to hold data through a long computation. The team encodes each logical qubit across many physical qubits with an error-correcting code. The code helps only if each physical qubit's error rate is below the code's threshold, so the team measures those rates first.
- P45: The function, a logical qubit, survives an error on any single physical qubit. The team makes sure each copy is reliable enough for the redundancy to help: the physical error rates are below the threshold. In a test, an error injected on any single physical qubit is corrected and the logical state survives.