Safety Norms: Software Architecture and Engineering Best Practices

1Purpose, Scope, and Safety Principles

Software architecture is the set of structural decisions that determine how components, data stores, interfaces, and infrastructure work together. In this context, safety means preventing harm to people, protecting the public from system failures, and avoiding damage to property, data, and the environment. These norms apply to design reviews, technology selection, system decomposition, deployment pipelines, production operations, and decommissioning.

Three principles guide every norm. First, design for failure: assume components will fail and define how the system degrades safely. Second, least privilege: every component, person, and process receives only the access it needs. Third, traceability: every significant decision is recorded with its rationale, owner, and review status. Where a system affects physical equipment, clinical outcomes, financial transactions, or legal rights, this guidance is a starting point only.

• MANDATORY: Any system handling personal, financial, or health data must have a documented owner before production release.
• RECOMMENDED: Keep architecture decision records short, covering context, options considered, decision, and consequences.

2Roles, Competence, and Accountability

The solution architect owns structural decisions and the written architecture description. The lead engineer owns implementation quality and code review. The operations or reliability lead owns runtime controls, capacity limits, and recovery procedures. A security and privacy reviewer approves data flows involving sensitive information. The product owner accepts residual business risk. Responsibility must be named for each system rather than shared vaguely across a team.

Competence is demonstrated, not assumed. Engineers who design authentication, payment flows, safety interlocks, or clinical data handling need documented training and supervised experience in those domains before approving their own designs. Where a system controls physical equipment or affects patient care, only people holding the relevant professional qualifications and organizational authorization may approve changes to safety functions. Production access is granted by role and revoked promptly when roles change.

• MANDATORY: Each production system has a named accountable owner recorded in the service catalog.
• MANDATORY: No engineer approves a change to a safety-related or privacy-related component without an independent reviewer.
• RECOMMENDED: Rotate on-call duties with written handoff notes and a maximum continuous shift length set by the operations lead.

3Course-Specific Hazards and Risk Assessment

Realistic hazards fall into several groups. Structural hazards include tightly coupled components, single points of failure, and unbounded retries that turn a small fault into a cascading outage. Data hazards include exposure of personal records, corruption from partial writes, and credentials leaking into logs or repositories. Change hazards arise from untested releases, schema migrations without rollback paths, and configuration drift between environments. Human hazards include fatigue during incident response, unclear ownership, and pressure to skip review.

Risk is assessed by combining likelihood with the severity of harm, including harm to users, staff, and the public. A common approach uses a five-point scale for each factor, with a combined score that triggers required actions. Scores at or above the agreed threshold require an architecture review before build and a documented mitigation plan. Assessments are repeated when data classification, user population, or external dependencies change. The accountable owner sets local scales and thresholds under the organization's governance process.

• Identify data classes, users, and external dependencies before the design review starts.
• Model at least these failure modes: dependency outage, data corruption, credential compromise, and loss of a site or region.
• Rate severity by the worst credible harm to people, not only by financial or service impact.

4Preventive Controls and Safe Change Practices

Preventive controls are built into the architecture and the delivery pipeline. Isolate components behind defined interfaces, set timeouts and circuit breakers on every remote call, and make operations idempotent wherever retries are possible. Protect state with transactional boundaries and validated migrations. Each deployment must be reversible, either by automated rollback or by a tested forward fix with a recovery time target set by the owner.

Production changes follow a permit-style gate. A change request states scope, risk rating, test evidence, rollback method, the signals to monitor, and the person authorized to start the change. High-risk changes, such as large-scale schema migrations, authentication changes, or changes to control software for physical equipment, require a second approver and a scheduled window. Emergency changes are allowed only under a documented emergency procedure and are reviewed afterward.

• MANDATORY: Production changes must pass automated tests, static analysis, and dependency vulnerability scanning before release.
• MANDATORY: Secrets must never be stored in source code, container images, or log output; use the approved secrets manager.
• MANDATORY: Every migration must have a tested rollback or a documented compensating procedure before execution.
• RECOMMENDED: Use canary releases and feature flags for changes affecting many users, with automated halt criteria.
• RECOMMENDED: Pin dependencies and review license terms and maintainer security practices before adoption.

5Environment, Tools, Information, and Protective Safeguards

Engineering work takes place on workstations, build servers, cloud accounts, and sometimes on-premises server rooms, data centers, or edge devices. Server rooms involve electrical, thermal, and lifting hazards. Only trained staff may work on power distribution, battery systems, or racks, and lone working in those areas is prohibited under site rules. Used hardware and batteries go through approved disposal channels. Electrical codes and waste regulations are jurisdiction-dependent; verify current versions with competent authorities and qualified facilities staff.

Information safeguards protect people. Classify data before it enters a system, minimize collection, encrypt data in transit and at rest using approved algorithms and key management, and log access to sensitive records. A privacy impact review is required before any new processing of personal data. Ergonomic safeguards also matter: adjust workstations for posture and schedule breaks during long debugging sessions. Physical site work follows the site's own protective rules, including hard hats, eye protection, and electrically rated gloves where required.

• Use managed, encrypted devices with screen locking for all production access.
• Never copy production personal data into development or test environments without masking and written approval.
• Apply lockout and tagging before any hands-on work with live electrical equipment.

6Incident Reporting, Emergency Response, and Escalation

Anyone who observes a security event, data exposure, user-facing outage, near miss, or unsafe physical condition must report it immediately through the defined channel. Near misses, such as a command that nearly deleted a backup set, are reported with the same seriousness as incidents because they reveal weak controls. Good-faith reports are protected from blame under the organization's policy.

The incident commander, usually the on-call lead, classifies severity, assigns roles, opens a coordination channel, and decides when to contain. Containment steps such as revoking credentials, disabling a feature, or isolating a segment follow the runbook. Breaches involving personal data trigger legal and compliance steps, and notification obligations and deadlines are jurisdiction-dependent and must be confirmed with counsel. For physical emergencies such as fire, electrical injury, or a medical event at a facility, personnel contact local emergency services first and then follow site evacuation procedures. Software staff do not fight fires or attempt rescues from energized equipment.

• MANDATORY: Report suspected personal data exposure to the privacy officer and security team within the window set by the incident procedure.
• MANDATORY: Preserve logs and evidence before rebuilding affected systems.
• RECOMMENDED: Hold a blameless review after resolution, with corrective actions tracked to verified completion.

7Records, Training, Inspection, and Review

Architecture documentation includes system context, component and data flow diagrams, decision records, threat models, risk assessments, runbooks, and test evidence. Records are kept in an approved repository with version control and access controls. Retention periods for records and logs are set by legal and policy requirements, which vary by jurisdiction and sector.

Training covers secure coding, privacy basics, incident reporting, rollback drills, and site-specific safety for anyone entering a facility. Failover tests and tabletop exercises for critical systems run at an interval the owner sets and records. Architecture reviews are repeated after major changes and at a fixed review interval. Metrics such as change failure rate, time to restore service, and overdue corrective actions guide improvement. Metrics must not be used to punish individuals, because that discourages reporting.

• Review threat models and high-risk decisions after any significant incident or design change.
• Track corrective actions with an owner, a target, and a verification step before closure.

Implementation checklist

• Confirm every production system has a named accountable owner in the service catalog.
• Complete a risk rating and threat model before design approval.
• Verify each change has a tested rollback method and a named authorizer.
• Remove secrets from code, images, and logs, and rotate any exposed credentials.
• Mask personal data before it leaves production and confirm a privacy review exists.
• Confirm on-call staff have current runbooks, access, and escalation contacts.
• Apply lockout and tagging before any hands-on work with live power equipment.
• Report near misses and incidents through the defined channel without delay.
• Test failover and rollback procedures at the agreed interval and record results.
• Verify applicable laws, standards, and vendor instructions with qualified professionals.