Reports and metrics

Reports & Metrics for Interrupt Topology Contracts focuses on interrupt latency tail, missed-interrupt incidents. The goal is to map symptoms to boundary contracts, owner actions, and regression-proof closure.

The job of a report is to convert interrupt latency tail, missed-interrupt incidents into a closure decision. One summary number is never enough without baseline, owner, and boundary context.

Metric movement

METRIC GRAPH — interrupt latency tail, missed-interrupt incidents

integration confidence
  ^
  |                         target
  |                       - - - - - - -
  |                  o post-fix + regression
  |              o
  |         o baseline
  |    o failing run
  +--------------------------------------> closure iteration
    baseline freeze   owner fix   full matrix

Readout:
  - compare results on the same manifest baseline
  - state owner and boundary with every metric movement

Risk distribution

RISK HISTOGRAM — Interrupt Topology Contracts

issue count
  |      ***
  |    *******
  |  ***********
  |*************  <- critical tail
  +--------------------> risk severity
   low   medium   high

Debug the high-severity tail first; averages hide escape risk.

• Track interrupt latency tail, missed-interrupt incidents by domain and owner boundary.

• Store baseline manifest beside every metric snapshot.

• Report both immediate fix result and full regression result.

• Explicitly call out residual risk and ownership.

SoC deep dive

Address, interrupt, and IO contracts are where hardware/software alignment is won or lost.

Concept diagram

HW/SW CONTRACT
address map + interrupt model + io defaults -> firmware behavior

Metric graph

BOOT REGRESSION SOURCES
map churn █████
reset defaults ████
driver mismatch ███

Reports and artifacts

• address decode audit

• interrupt latency report

• IO bring-up checklist

• boot contract review

Mini case study

A map alias issue caused sporadic peripheral misconfiguration despite clean block-level tests.

Debug branches

• Freeze address map baseline

• Audit reset defaults

• Validate firmware assumptions

Senior review question

Ask: what baseline, owner, and artifact prove this topic is truly closed?

Key takeaways

• State baseline manifest and owner with every closure metric.

• Run cross-domain regression after every top-level fix.

Common pitfalls

• Comparing results across different manifests.

• Unowned issues slipping through review cycles.

• Waiving risks without expiry and validation plan.

Reading integration reports