Skip to main content
Back to Prompt Library
implementation

Build the application

Inspect the original prompt language first, then copy or adapt it once you know how it fits your workflow.

Linked challenge: Build an open62541 Material Substitution Compliance Auditor

Format
Code-aware
Lines
89
Sections
11
Linked challenge
Build an open62541 Material Substitution Compliance Auditor

Prompt source

Original prompt text with formatting preserved for inspection.

89 lines
11 sections
No variables
1 code block
## Build
Parse open62541 OPC UA lot tracking records to verify material substitutions in multi-level assemblies. Flag products using unauthorized alternative components against master bill-of-materials rules to maintain quality compliance.

## User
Plant Quality Compliance Engineer

## Workflow
1. Extract serialized component binding logs and material identifiers from open62541 OPC UA structures.
2. Retrieve authorized substitution lists and primary component requirements from the master bill-of-materials.
3. Compare actual consumed component lots against authorized substitution lists for each assembly level.
4. Generate substitution compliance exception reports detailing unauthorized lot usages and affected product serial numbers.

## Interface
Audit dashboard web UI displaying compliance statuses and flagged unauthorized material substitutions.

## Data
Create simplified synthetic app records representing normalized open62541 hierarchical assembly data and master BOM substitution rules in JSON fixtures.
Starter examples below are synthetic. They are not downloaded records.

## Source
[open62541 OPC UA](https://raw.githubusercontent.com/open62541/open62541/master/README.md)
Uses the open62541 OPC UA information modeling guidelines for hierarchical variable nodes to map component usage.

## Tools
qdrant, pydantic, fastapi.
Qdrant enables rapid vector and metadata filtering to cross-reference consumed materials against allowed substitution sets across deep assembly hierarchies.
Requires a local or remote reasoning model to process multi-level BOM structures and apply substitution rules.

## Deliverables
Submit runnable source, pinned dependencies, setup commands, a working interface, example outputs, and a recorded end-to-end demo. Include tests and an action log.

## Acceptance
- Traces components in the open62541 hierarchy to verify their presence in BOM substitution lists.
- Generates exception reports for sub-assemblies containing unapproved materials.
- Handles multi-level assemblies safely without recursive deadlocks.
- Flags empty or malformed material records where required components are missing.

## Starter Examples
```json
[
  {
    "input": {
      "assembly_id": "ASSY-505",
      "consumed_components": [
        {
          "part_id": "RESISTOR-10K-A",
          "lot": "L-99",
          "qty": 1
        }
      ],
      "master_bom_allowed": {
        "RESISTOR-10K": [
          "RESISTOR-10K-STD",
          "RESISTOR-10K-ALT1"
        ]
      }
    },
    "expected_output": {
      "assembly_id": "ASSY-505",
      "compliance_status": "UNAUTHORIZED_SUBSTITUTION",
      "violations": [
        {
          "expected_category": "RESISTOR-10K",
          "used_part": "RESISTOR-10K-A"
        }
      ],
      "audit_passed": false
    }
  },
  {
    "input": {
      "assembly_id": "ASSY-506",
      "consumed_components": [
        {
          "part_id": "RESISTOR-10K-ALT1",
          "lot": "L-100",
          "qty": 1
        }
      ],
      "master_bom_allowed": {
        "RESISTOR-10K": [
          "RESISTOR-10K-STD",
          "RESISTOR-10K-ALT1"
        ]
      }
    },
    "expected_output": {
      "assembly_id": "ASSY-506",
      "compliance_status": "COMPLIANT",
      "violations": [],
      "audit_passed": true
    }
  }
]
```

## Safety
Outputs compliance audit suggestions for warehouse and quality verification; does not issue live ERP commands.
Use mock external writes. Require human review before any real deployment.

Adaptation plan

Keep the source stable, then change the prompt in a predictable order so the next run is easier to evaluate.

Keep stable

Hold the task contract and output shape stable so generated implementations remain comparable.

Tune next

Update libraries, interfaces, and environment assumptions to match the stack you actually run.

Verify after

Test failure handling, edge cases, and any code paths that depend on hidden context or secrets.