Join the pilot
04 / CONFIGURATION

OMERA.md Configuration

Learn how to write project-level configuration rules inside the OMERA.md file to control compilation, simulations, safety constraints, and evidence thresholds.

Overview

The OMERA.md file acts as the project-level contract between your repository and the Omera 3.6 engine. Placed at the root of your workspace, it governs the code generation boundaries and enforces pin assignments, compilation tools, and testing configurations.

File Structure

The configuration utilizes standard Markdown with frontmatter block syntax:

---
board_id: STM32F407VG
netlist: schematic.net
output_dir: build_output/
ai_mode: auto
safety:
  enforce: true
  block_actuators: true
  forbidden_pin_states:
    - pin: PA5
      state: HIGH
      reason: "High current hazard on LED output line"
---

# Project Design Specs

Describe design intent here. Omera parses this description as RAG context.

Configuration Key Reference

KeyTypeDefaultDescription
board_idstring—The target MCU identifier (e.g. STM32F407VG, ESP32-S3).
netliststring—Path to your KiCad schematic .net/.xml or Altium .NET file.
output_dirstringoutput/Directory path where generated source code and logs are stored.
ai_modestringautoAI execution mode: local (BYOK keys) or account (Omera backend).
safety.enforcebooleantrueIf true, blocks pipeline compilation if safety checks fail.
safety.block_actuatorsbooleantrueDisables test-firing of actuators during hardware-in-the-loop tests.

Declaring Design Intent

The body of your OMERA.md file contains natural language specifications about the hardware functionality. Omera 3.6 reads this section to understand:

  • Sensor sampling rates (e.g. "Read BME280 sensor values every 5000ms").
  • Communication protocol rates (e.g. "Run SPI1 at 10 MHz in Mode 0").
  • RTOS Task priority models (e.g. "Assign priority 3 to the watchdog monitor task").

This approach keeps specifications next to code, ensuring they remain version-controlled and source-synchronized.