WBF wrapper component interactions

flowchart LR
  Windows[Windows Biometric Framework] --> Adapter[Sensor / Engine / Storage adapters]
  Adapter --> Device[CBiometricDriver + CBiometricDevice]
  Device --> Capture[CaptureImage + worker threads]
  Device --> Power[Power, wake, pairing and side-channel control]
  Capture --> Bridge[vfmCoreEntry]
  Power --> Bridge
  Adapter --> Bridge
  Bridge --> Core[niseCore VFM API]
  Device --> Bus[USB / SPI / HID device classes]
  Bus --> Sensor[Fingerprint sensor]
  Customer[CustomerProjects props] -. configures .-> Adapter
  Customer -. configures .-> Device
  Services[Policy / reset / monitor / CTAP services] --> Device
  Package[Driver and service packages] -. delivers .-> Device

The arrows show dependency or runtime/control flow supported by the source structure and entrypoints at 10b4330a37b3. Dotted arrows mean configuration or validation rather than a runtime call. The wrapper owns host request/update orchestration; firmware command implementation is external. See project firmware integration.

Interaction contracts

From/toContract
WBDI driverOwns CBiometricDriver/CBiometricDevice, WDF requests, capture threads, power/wake handling and USB/SPI/HID transports.
WBF adaptersImplements sensor, engine and storage adapter callbacks plus generic adapter state.
niseCore bridgeMaps Windows driver operations to the VFM/niseCore API.
Capture pipelineCoordinates asynchronous capture, cancellation, completion and notify-wake.
Customer projectsDefines per-customer properties, matcher/options, package and feature selection.
ServicesProvides policy/reset/monitoring/analysis and CTAP-related services where selected.
Installer/packageBuilds driver/service packages and install-time components.
Optional UI/utilitiesSupplies customer-selected applications, RPC/UWP service and diagnostics.

Evidence