HILIGHTer Digital TwinProfiles
Profiles

Instrument profiles

Instrument profiles are complete saved controller states representing reproducible virtual instruments. They are the main way to switch between reference systems, vendor-derived configurations, and in-house designs.

JSON structure

Plain English

A profile stores the active instrument configuration plus descriptive metadata. It is not just a gate preset; it can encode excitation, detector, gating, optimisation defaults, and profile metadata.

For specialists

The profile store persists versioned JSON under python/profiles/instruments/. The payload is a sanitised PhysicsConfig plus metadata and profile-type information. The expected structure is also exposed through MCP via get_instrument_profile_schema.

Repair and sanitise

If an older profile is missing fields or contains obsolete ones, the manager can repair it. Repair writes the sanitised form back to disk, so the file becomes forward-compatible for the next load.

Preview and apply

The profile manager shows compatibility status and a diagnostics preview before application. The preview now reports gate-property diagnostics such as ideal-gate status, gate count, overlap mode, wrap-around, and gate rise/fall. Applying a profile updates the workspace config atomically.

Vendor-derived profiles

The repository now includes vendor-style instrument definitions created from documentation. Profiles can encode:

  • TCSPC electronics and detector timing limits
  • laser repetition period and equal-bin gate layouts
  • multihit capacity assumptions
  • ideal-gate assumptions where documentation does not specify non-ideal gate shapes
  • laser pulse position and practical detector timing-jitter choices

MCP-assisted profile creation

The current preferred LLM workflow is:

1. list_vendor_sources
2. read_vendor_source
3. get_instrument_profile_schema
4. draft_instrument_profile
5. ask the user to confirm missing assumptions
6. finalize_instrument_profile

The older ingest_instrument_profile_source tool still exists as a convenience path, but the structured draft/finalise workflow is the current intended one because it lets the model explicitly expose missing assumptions and request confirmation before saving the profile.