archelps/arc-engineering
100 AI skills for systems and hardware engineers: requirements review, electrical and mechanical interfaces, power and mass budgets, environmental qualification, FMEA and verification. Includes local MCP file tools.
Allocate a system performance limit across contributing stages and calculate remaining margin.
Propose requirement-to-system allocations with a reasoned ownership boundary.
Perform functional allocation: allocate stated system functions to responsible subsystems and reveal unowned or overlapping behavior.
Propose traceable subsystem reliability budgets that satisfy an approved system success target under explicit architecture assumptions.
Examine shared exposures and dependencies that can defeat claimed redundancy in a defined architecture.
Assess qualification need from a tool’s intended use, output credit, and downstream error detection.
Trace a proposed Interface revision across both endpoints, requirements, integration, and evidence.
Assess technical feasibility and integration consequences of building versus buying a component.
Trace a proposed Requirement revision to affected design, interfaces, tests, and evidence.
Assess executed data against a specific requirement and approved acceptance rule.
Construct a traceable Boolean fault tree for one defined top event and analyze its minimal cut sets and assumptions.
Build a requirement traceability matrix (RTM) from stable IDs, recorded links, and verification evidence.
Build a traceable matrix from requirements to planned verification evidence.
Build a mass budget from component estimates, configuration, and a stated system allowance.
Build a mode-specific electrical power budget from loads and source capability.
Track review actions from finding to evidence-backed closure recommendation without losing original board decisions.
Organize bidder response obligations against tender clauses with evidence and unresolved exceptions.
Calculate a bounded system reliability estimate from component data and a defined success model.
Check whether a proposed baseline contains the intended scope, revisions, documents, and review evidence.
Map supplied software lifecycle evidence to the applicable DO-178C objectives for an approved software level.
Assess airborne electronic hardware evidence against the approved DO-254/ED-80 basis and hardware DAL.
Calculate signed engineering margin and judge it only against stated requirements and conventions.
Assess whether objective evidence could decide a requirement at the stated level and configuration.
Compare an existing procedure’s actions and criteria with the full requirement obligation.
Check calculation expressions for unit consistency, conversions, and physical dimensional meaning.
Prepare a source-preserving column map and reviewed import proposal from a messy requirements spreadsheet.
Compare feasible architectures against stated decision criteria, assumptions, and evidence.
Assess whether existing children preserve, cover, or exceed a parent requirement.
Compare two exact engineering baselines and explain material model and evidence changes.
Compare two parties’ interface specifications and record matches, conflicts, and missing evidence.
Produce a semantic change register between two controlled specification versions.
Perform functional or product decomposition: propose a System hierarchy from responsibilities and physical or logical boundaries.
Turn an approved requirement into observable pass/fail criteria without inventing thresholds.
Define a system-of-interest boundary, external actors, and crossings from a stated mission or product scope.
Define an engineering exchange between two Systems and propose its Interface relationship content.
Define a small set of decision-useful TPMs with sources, trends, and project-approved action thresholds.
Draft auditable readiness and completion gates for a bounded verification campaign.
Turn an agreed system boundary and exchanged items into candidate interface obligations.
Turn approved hazard controls into proposed measurable safety requirements with traceable rationale.
Propose child requirements that partition an approved parent obligation without losing or inventing intent.
Write normal and off-nominal operational scenarios with triggers, actions, responses, and recovery paths.
Use integration logs and configuration evidence to narrow a failure and propose discriminating checks.
Extract candidate obligations from a customer document with exact source trace and ambiguity flags.
Find requirements whose simultaneous obligations cannot be reconciled under the same conditions.
Identify exact and semantic duplicates while preserving distinct conditions and source obligations.
Find interface behaviors that lack an explicit, allocated, verifiable Requirement.
Find unsupported scenario transitions and exceptions that need requirement decisions.
Identify verification evidence whose tested configuration may no longer support the changed model.
Find terms whose missing or inconsistent definitions materially change interpretation or verification.
Find baseline obligations lacking adequate planned Tests or current evidence.
Map ReqIF objects and relations into a reviewed local requirements proposal while preserving external IDs.
Analyze credible item failure modes, their local and system effects, detection, and existing controls for a configured design.
Assess loss and malfunction of intended functions across operating conditions and document candidate failure conditions.
Identify credible early lifecycle hazards and record assumptions, controls, and follow-up evidence for a defined system concept.
Identify and assess credible technical risk scenarios against project objectives and existing controls.
Choose targeted re-verification actions after a change using actual affected obligations and evidence.
Sequence subsystem integration using dependencies, test access, and fault-isolation needs.
Prepare a CDR packet assessing whether detailed design and build-to data are mature for implementation and integration.
Prepare a reviewable engineering change request with rationale, exact deltas, impacts, and validation.
Prepare an ORR packet assessing deployed system, support products, people, procedures, and contingency readiness.
Prepare a PDR packet that tests preliminary architecture, interface choices, margins, and path to detailed design.
Prepare a decision-ready SRR packet focused on requirements completeness, feasibility, and baseline readiness.
Prepare a TRR packet checking test article, facility, procedures, personnel, safety, and data capture readiness.
Prepare source-backed decisions for unresolved requirement placeholders without silently choosing values.
Review a data exchange for syntax, semantics, timing, state, and error behavior.
Review the reasoning and authority trail for functional, item, software, and hardware assurance allocations.
Review a proposed deviation or waiver against a specific requirement, configuration, evidence, and authority.
Assess whether a proposed closure addresses a stated ECSS finding using current, applicable evidence.
Review an electrical interface for complete, consistent power, signal, grounding, and fault parameters.
Check that qualification evidence spans approved environments, configurations, and requirement limits.
Review FDIR sequences against fault effects, timing, safe-state behavior, and verification evidence.
Find credible omissions in an existing FMEA against actual functions, interfaces, and operating modes.
Find missing or weakly allocated functions by walking scenarios, requirements, and function flows.
Check whether each claimed hazard control has applicable, current, and sufficient implementation and verification evidence.
Review end-to-end interface latency by tracing stages, bounds, clocks, and operating conditions.
Check maintainability requirements for measurable repair, access, support, and operating context.
Review mating geometry, loads, tolerances, access, and installation assumptions across two Systems.
Check applicability, tailoring, evidence, and approval in an NPR 7150.2D Appendix C mapping matrix.
Check whether a reliability block diagram represents the actual success logic, dependencies, and mission scope.
Review one requirement against an inspected, applicable edition of ECSS-E-ST-10-06 and return source-grounded findings.
Review one requirement against a user-accessible licensed INCOSE guide edition without inventing rules.
Assess whether rationale explains the obligation and supports future change decisions.
Find missing technical risks and rewrite vague entries as cause-event-consequence statements.
Challenge the links among safety claims, assumptions, subclaims, and configuration-specific evidence.
Identify architecture elements whose single failure may defeat a stated function or mission outcome.
Review the basis, scope, rationale, and approval of an engineering standards applicability matrix.
Challenge supplier claim strength against exact requirement, configuration, and supplied proof.
Review a specific supplier engineering deliverable against agreed content, interfaces, evidence, and configuration.
Review operating modes, guards, transitions, and recovery for ambiguous or unreachable behavior.
Evaluate claimed TRL or technology maturity against what was demonstrated in the relevant environment.
Decide whether existing verification evidence applies to the current requirement and product configuration.
Review matrix completeness and source-grounded ECSS-E-ST-10-02 obligations for a controlled edition.
Rewrite a requirement in an appropriate EARS pattern while preserving its engineering intent.
Choose a defensible inspection, analysis, demonstration, or test approach for one requirement.
Build an evidence-backed trace from technical requirements to stated stakeholder needs.
Draft a concept of operations (ConOps) connecting actors, goals, phases, modes, and outcomes for a defined system.
Draft an interface control document (ICD) from agreed System endpoints and controlled exchange details.
Draft executable steps and records that can verify a requirement on a defined article.
Plan concrete actions, triggers, and evidence to reduce a stated technical risk scenario.
Synthesize verification status and open exceptions for a named baseline and article.