ometere123/the-skills-bible/advanced-systems-architect

Advanced Systems Architect

Purpose

Design complex physical-digital systems across hardware, software, models, networks, humans, safety, operations, and lifecycle.

Use this skill when

• The work directly concerns mission and system boundary, stakeholder and authority model, or operating modes and states.
• Hardware, physics, timing, autonomy, scientific computation, or specialised human factors materially affect correctness.
• A design, implementation, validation, migration, or operational decision needs reproducible evidence.
• Existing behaviour is under-specified, physically risky, or difficult to diagnose.

Do not use this skill as the primary workflow when

• A conventional software system fully satisfies the requirement.
• The request seeks bypassing safety, security, regulatory, or physical controls.
• The system boundary, operating environment, or accountable authority cannot be identified.
• A narrower implementation, testing, or operations skill is the actual task.

Required inputs

• Mission, intended use, users, operators, affected people, and operating environment.
• Hardware revisions, schematics, firmware, software, models, parameters, interfaces, and configuration.
• Signals, units, coordinate frames, rates, clocks, power, thermal, mechanical, and environmental constraints.
• Hazards, safe states, permissions, security, reliability, and recovery objectives.
• Test equipment, simulators, HIL rigs, field data, acceptance criteria, and lifecycle policy.

Classify missing information as blocking, important, or optional. Inspect real artefacts and evidence before requesting information that can be verified directly.

Core operating principles

• Define physical, computational, human, environmental, and organisational boundaries before selecting technology.
• Separate sensing, estimation, planning, control, actuation, supervision, safety, and business logic.
• Treat timing, units, frames, calibration, uncertainty, saturation, and failure modes as explicit contracts.
• Preserve safe state, bounded authority, graceful degradation, manual intervention, and recoverability.
• Use deterministic control for safety-critical behaviour and constrain probabilistic components to validated envelopes.
• Design for noise, drift, wear, occlusion, communication loss, power loss, thermal limits, and component variation.
• Record exact hardware, firmware, software, models, parameters, calibration, and test configuration.
• Validate in simulation, bench, hardware-in-the-loop, controlled field trials, and representative environments.
• Protect devices, operators, bystanders, data, and supply chains throughout the lifecycle.
• Convert failures and near misses into updated hazards, requirements, tests, monitoring, and procedures.

Workflow

1. Mission And System Boundary

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for mission and system boundary.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

2. Stakeholder And Authority Model

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for stakeholder and authority model.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

3. Operating Modes And States

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for operating modes and states.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

4. Functional Decomposition

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for functional decomposition.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

5. Physical And Digital Interfaces

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for physical and digital interfaces.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

6. Timing And Resource Budgets

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for timing and resource budgets.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

7. Safety And Security Architecture

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for safety and security architecture.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

8. Verification Strategy

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for verification strategy.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

9. Operations And Maintainability

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for operations and maintainability.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

10. Lifecycle And Decommissioning

• Define the objective, boundary, owners, inputs, outputs, assumptions, and constraints for lifecycle and decommissioning.
• Inspect current hardware, software, models, configuration, telemetry, and operating evidence.
• Specify normal, boundary, degraded, maintenance, and recovery behaviour.
• Produce a versioned artefact or test that can be independently reviewed and reproduced.

Decision rules

Required outputs

• Mission And System Boundary specification, evidence, and acceptance criteria.
• Stakeholder And Authority Model specification, evidence, and acceptance criteria.
• Operating Modes And States specification, evidence, and acceptance criteria.
• Functional Decomposition specification, evidence, and acceptance criteria.
• Physical And Digital Interfaces specification, evidence, and acceptance criteria.
• Timing And Resource Budgets specification, evidence, and acceptance criteria.
• Safety And Security Architecture specification, evidence, and acceptance criteria.
• Verification Strategy specification, evidence, and acceptance criteria.
• Operations And Maintainability specification, evidence, and acceptance criteria.
• Lifecycle And Decommissioning specification, evidence, and acceptance criteria.

Advanced-system quality gates

• System gate: Boundaries, interfaces, modes, states, actors, and operating environment are explicit.
• Timing gate: Deadlines, rates, jitter, latency, synchronisation, and worst-case behaviour are measured.
• Safety gate: Hazards, safe states, interlocks, limits, supervision, and emergency actions are verified.
• Uncertainty gate: Noise, calibration, confidence, drift, and out-of-distribution behaviour are handled.
• Control gate: Stability, saturation, constraints, authority, and degraded control are validated.
• Hardware gate: Electrical, mechanical, thermal, power, environmental, and manufacturing limits are respected.
• Software gate: Firmware, drivers, models, configuration, and update paths are reproducible.
• Validation gate: Simulation, bench, HIL, field, fault injection, and acceptance evidence cover representative risk.
• Operations gate: Monitoring, maintenance, diagnostics, incident response, rollback, and manual fallback are ready.
• Lifecycle gate: Provisioning, calibration, updates, repair, replacement, decommissioning, and disposal are governed.

Evidence standard

Identify exact hardware revision, firmware and software versions, model and parameter versions, device identity, calibration, frames, clock source, power and thermal state, operating mode, environment, scenario, data set, and observation window. Distinguish simulation, laboratory, HIL, controlled field, production observation, supported inference, and unresolved uncertainty.

Failure handling and escalation

Pause or escalate when the operating environment, safety boundary, control authority, or safe state is unclear; sensor, actuator, clock, power, thermal, calibration, or communication integrity cannot be established; a system may move or energise unexpectedly; a probabilistic component operates outside its validated envelope; or testing could create physical danger or irreversible hardware damage. Preserve evidence and place the system in a controlled condition before diagnosis.

Common anti-patterns

• Treating mission and system boundary as implicit or universally understood.
• Omitting physical units, coordinate frames, timestamps, calibration, or hardware revision.
• Optimising nominal behaviour while ignoring degraded and maintenance modes.
• Allowing probabilistic output to command unsafe action without deterministic limits.
• Treating simulation as complete field validation.
• Updating firmware, models, or parameters without compatibility and rollback evidence.
• Relying on average latency or accuracy where worst-case behaviour matters.
• Closing incidents without updating hazards, tests, and operating procedures.

Completion checklist

• [ ] System boundary and intended environment are explicit.
• [ ] Interfaces include units, frames, rates, timing, and authority.
• [ ] Hazards, safe states, and degraded modes are testable.
• [ ] Hardware, software, model, and calibration versions are reproducible.
• [ ] Simulation, bench, HIL, or field evidence matches the risk.
• [ ] Operators can diagnose, intervene, and recover safely.
• [ ] Lifecycle and update paths are governed.
• [ ] Residual risk has an accountable owner.

Advanced-system implementation record

# Advanced-System Implementation Record
 
## Outcome
[Physical, autonomous, scientific, or operational outcome]
 
## System boundary
[Hardware, software, environment, operators, and exclusions]
 
## Interfaces
[Signals, units, frames, rates, protocols, timing, power, and authority]