Edit Metrics: trim verbose opening, add graded responses scope justification

4-metrics-of-success/metrics.tex

@@ -6,33 +6,36 @@ demonstration. This work begins at TRL 2--3 and aims to reach TRL 5, where
 system components operate successfully in a relevant laboratory
 environment.\splitnote{TRL as primary metric is smart — speaks industry
 language.}
-This section explains why TRL advancement provides the most appropriate success
-metric and defines the specific criteria required to achieve TRL 5.
+This section explains why TRL advancement provides the most appropriate
+success metric and defines the specific criteria required to achieve TRL 5.
 
-Technology Readiness Levels provide the ideal success metric because they
-explicitly measure the gap between academic proof-of-concept and 
-practical\dasinline{Chop. No likey.}
-deployment---precisely what this work aims to bridge. Academic metrics like
-papers published or theorems proved cannot capture practical feasibility.
-Empirical metrics like simulation accuracy or computational speed cannot
-demonstrate theoretical rigor. TRLs measure both dimensions 
-simultaneously.\splitnote{Good framing — explains why other metrics are 
-insufficient.}
-Advancing from TRL 3 to TRL 5 requires maintaining theoretical rigor while
-progressively demonstrating practical feasibility. Formal verification must
-remain valid as the system moves from individual components to integrated
-hardware testing.
+\oldt{Technology Readiness Levels provide the ideal success metric because
+they explicitly measure the gap between academic proof-of-concept and
+practical deployment---precisely what this work aims to bridge. Academic
+metrics like papers published or theorems proved cannot capture practical
+feasibility. Empirical metrics like simulation accuracy or computational
+speed cannot demonstrate theoretical rigor. TRLs measure both dimensions
+simultaneously.} \newt{TRLs measure the gap between academic
+proof-of-concept and practical deployment, which is precisely what this work
+aims to bridge. Academic metrics alone cannot capture practical feasibility,
+and empirical metrics alone cannot demonstrate theoretical rigor. TRLs
+measure both simultaneously.}\dasinline{Chop. No likey.}\splitnote{Good
+framing — explains why other metrics are insufficient.} Advancing from TRL 3
+to TRL 5 requires maintaining theoretical rigor while progressively
+demonstrating practical feasibility. Formal verification must remain valid as
+the system moves from individual components to integrated hardware testing.
 
 The nuclear industry requires extremely high assurance before deploying new
 control technologies. Demonstrating theoretical correctness alone is
 insufficient for adoption; conversely, showing empirical performance without
-formal guarantees fails to meet regulatory requirements. TRLs capture this dual
-requirement naturally. Each level represents both increased practical maturity
-and sustained theoretical validity. Furthermore, TRL assessment forces explicit
-identification of remaining barriers to deployment. The nuclear industry already
-uses TRLs for technology assessment, making this metric directly relevant to
-potential adopters. Reaching TRL 5 provides a clear answer to industry questions
-about feasibility and maturity that academic publications alone cannot.
+formal guarantees fails to meet regulatory requirements. TRLs capture this
+dual requirement naturally. Each level represents both increased practical
+maturity and sustained theoretical validity. Furthermore, TRL assessment
+forces explicit identification of remaining barriers to deployment. The
+nuclear industry already uses TRLs for technology assessment, making this
+metric directly relevant to potential adopters. Reaching TRL 5 provides a
+clear answer to industry questions about feasibility and maturity that
+academic publications alone cannot.
 
 Moving from current state to target requires achieving three intermediate
 levels, each representing a distinct validation milestone:
@@ -45,8 +48,8 @@ temporal logic specifications that pass realizability analysis. A discrete
 automaton must be synthesized with interpretable structure. At least one
 continuous controller must be designed with reachability analysis proving
 transition requirements are satisfied. Independent review must confirm that
-specifications match intended procedural behavior. This proves the fundamental
-approach on a simplified startup sequence.
+specifications match intended procedural behavior. This proves the
+fundamental approach on a simplified startup sequence.
 
 \paragraph{TRL 4 \textit{Laboratory Testing of Integrated Components}}
 
@@ -57,41 +60,44 @@ must exist for all discrete modes. Verification must be complete for all mode
 transitions using reachability analysis, barrier certificates, and
 assume-guarantee contracts. The integrated controller must execute complete
 startup sequences in software simulation with zero safety violations across
-multiple consecutive runs. This proves that formal correctness guarantees can be
-maintained throughout system integration.
+multiple consecutive runs. This proves that formal correctness guarantees can
+be maintained throughout system integration.
 
 \paragraph{TRL 5 \textit{Laboratory Testing in Relevant Environment}}
 
 For this research, TRL 5 means demonstrating the verified controller on
-industrial control hardware through hardware-in-the-loop testing. The discrete
-automaton must be implemented on the Emerson Ovation control system and verified
-to match synthesized specifications exactly. Continuous controllers must execute
-at required rates. The ARCADE interface must establish stable real-time
-communication between the Emerson Ovation hardware and SmAHTR simulation.
-Complete autonomous startup sequences must execute via hardware-in-the-loop
-across the full operational envelope. The controller must handle off-nominal
-scenarios to validate that expulsory modes function correctly. For example,
-simulated sensor failures must trigger appropriate fault detection and mode
-transitions, and loss-of-cooling scenarios must activate SCRAM procedures as
-specified. Graded responses to minor disturbances are outside this work's 
-scope.\splitsuggest{Consider noting why graded responses are out of scope — 
-is it time, complexity, or scope creep? Brief justification helps.}
-Formal verification results must remain valid, with discrete behavior matching
+industrial control hardware through hardware-in-the-loop testing. The
+discrete automaton must be implemented on the Emerson Ovation control system
+and verified to match synthesized specifications exactly. Continuous
+controllers must execute at required rates. The ARCADE interface must
+establish stable real-time communication between the Emerson Ovation hardware
+and SmAHTR simulation. Complete autonomous startup sequences must execute via
+hardware-in-the-loop across the full operational envelope. The controller
+must handle off-nominal scenarios to validate that expulsory modes function
+correctly. For example, simulated sensor failures must trigger appropriate
+fault detection and mode transitions, and loss-of-cooling scenarios must
+activate SCRAM procedures as specified. Graded responses to minor
+disturbances are outside this work's scope\oldt{.}\newt{, as they require
+runtime optimization under uncertainty that extends beyond the
+correct-by-construction verification framework presented
+here.}\splitsuggest{Consider noting why graded responses are out of scope —
+is it time, complexity, or scope creep? Brief justification helps.} Formal
+verification results must remain valid, with discrete behavior matching
 specifications and continuous trajectories remaining within verified bounds.
-This proves that the methodology produces verified controllers implementable on
-industrial hardware.
+This proves that the methodology produces verified controllers implementable
+on industrial hardware.
 
 Progress will be assessed quarterly through collection of specific data
 comparing actual results against TRL advancement criteria. Specification
 development status indicates progress toward TRL 3. Synthesis results and
 verification coverage indicate progress toward TRL 4. Simulation performance
-metrics and hardware integration milestones indicate progress toward TRL 5. The
-research plan will be revised only when new data invalidates fundamental
+metrics and hardware integration milestones indicate progress toward TRL 5.
+The research plan will be revised only when new data invalidates fundamental
 assumptions. This research succeeds if it achieves TRL 5 by demonstrating a
 complete autonomous hybrid controller with formal correctness guarantees
-operating on industrial control hardware through hardware-in-the-loop testing in
-a relevant laboratory environment. This establishes both theoretical validity
-and practical feasibility, proving that the methodology produces verified
-controllers and that implementation is achievable with current 
-technology.\splitnote{Clear success criteria. Committee will know exactly 
-what ``done'' looks like.}
+operating on industrial control hardware through hardware-in-the-loop
+testing in a relevant laboratory environment. This establishes both
+theoretical validity and practical feasibility, proving that the methodology
+produces verified controllers and that implementation is achievable with
+current technology.\splitnote{Clear success criteria. Committee will know
+exactly what ``done'' looks like.}