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
+This section explains why TRL advancement provides the most appropriate
-metric and defines the specific criteria required to achieve TRL 5.
+success metric and defines the specific criteria required to achieve TRL 5.
 
-Technology Readiness Levels provide the ideal success metric because they
+\oldt{Technology Readiness Levels provide the ideal success metric because
-explicitly measure the gap between academic proof-of-concept and 
+they explicitly measure the gap between academic proof-of-concept and
-practical\dasinline{Chop. No likey.}
+practical deployment---precisely what this work aims to bridge. Academic
-deployment---precisely what this work aims to bridge. Academic metrics like
+metrics like papers published or theorems proved cannot capture practical
-papers published or theorems proved cannot capture practical feasibility.
+feasibility. Empirical metrics like simulation accuracy or computational
-Empirical metrics like simulation accuracy or computational speed cannot
+speed cannot demonstrate theoretical rigor. TRLs measure both dimensions
-demonstrate theoretical rigor. TRLs measure both dimensions 
+simultaneously.} \newt{TRLs measure the gap between academic
-simultaneously.\splitnote{Good framing — explains why other metrics are 
+proof-of-concept and practical deployment, which is precisely what this work
-insufficient.}
+aims to bridge. Academic metrics alone cannot capture practical feasibility,
-Advancing from TRL 3 to TRL 5 requires maintaining theoretical rigor while
+and empirical metrics alone cannot demonstrate theoretical rigor. TRLs
-progressively demonstrating practical feasibility. Formal verification must
+measure both simultaneously.}\dasinline{Chop. No likey.}\splitnote{Good
-remain valid as the system moves from individual components to integrated
+framing — explains why other metrics are insufficient.} Advancing from TRL 3
-hardware testing.
+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
+formal guarantees fails to meet regulatory requirements. TRLs capture this
-requirement naturally. Each level represents both increased practical maturity
+dual requirement naturally. Each level represents both increased practical
-and sustained theoretical validity. Furthermore, TRL assessment forces explicit
+maturity and sustained theoretical validity. Furthermore, TRL assessment
-identification of remaining barriers to deployment. The nuclear industry already
+forces explicit identification of remaining barriers to deployment. The
-uses TRLs for technology assessment, making this metric directly relevant to
+nuclear industry already uses TRLs for technology assessment, making this
-potential adopters. Reaching TRL 5 provides a clear answer to industry questions
+metric directly relevant to potential adopters. Reaching TRL 5 provides a
-about feasibility and maturity that academic publications alone cannot.
+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
+specifications match intended procedural behavior. This proves the
-approach on a simplified startup sequence.
+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
+multiple consecutive runs. This proves that formal correctness guarantees can
-maintained throughout system integration.
+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
+industrial control hardware through hardware-in-the-loop testing. The
-automaton must be implemented on the Emerson Ovation control system and verified
+discrete automaton must be implemented on the Emerson Ovation control system
-to match synthesized specifications exactly. Continuous controllers must execute
+and verified to match synthesized specifications exactly. Continuous
-at required rates. The ARCADE interface must establish stable real-time
+controllers must execute at required rates. The ARCADE interface must
-communication between the Emerson Ovation hardware and SmAHTR simulation.
+establish stable real-time communication between the Emerson Ovation hardware
-Complete autonomous startup sequences must execute via hardware-in-the-loop
+and SmAHTR simulation. Complete autonomous startup sequences must execute via
-across the full operational envelope. The controller must handle off-nominal
+hardware-in-the-loop across the full operational envelope. The controller
-scenarios to validate that expulsory modes function correctly. For example,
+must handle off-nominal scenarios to validate that expulsory modes function
-simulated sensor failures must trigger appropriate fault detection and mode
+correctly. For example, simulated sensor failures must trigger appropriate
-transitions, and loss-of-cooling scenarios must activate SCRAM procedures as
+fault detection and mode transitions, and loss-of-cooling scenarios must
-specified. Graded responses to minor disturbances are outside this work's 
+activate SCRAM procedures as specified. Graded responses to minor
-scope.\splitsuggest{Consider noting why graded responses are out of scope — 
+disturbances are outside this work's scope\oldt{.}\newt{, as they require
-is it time, complexity, or scope creep? Brief justification helps.}
+runtime optimization under uncertainty that extends beyond the
-Formal verification results must remain valid, with discrete behavior matching
+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
+This proves that the methodology produces verified controllers implementable
-industrial hardware.
+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
+metrics and hardware integration milestones indicate progress toward TRL 5.
-research plan will be revised only when new data invalidates fundamental
+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
+operating on industrial control hardware through hardware-in-the-loop
-a relevant laboratory environment. This establishes both theoretical validity
+testing in a relevant laboratory environment. This establishes both
-and practical feasibility, proving that the methodology produces verified
+theoretical validity and practical feasibility, proving that the methodology
-controllers and that implementation is achievable with current 
+produces verified controllers and that implementation is achievable with
-technology.\splitnote{Clear success criteria. Committee will know exactly 
+current technology.\splitnote{Clear success criteria. Committee will know
-what ``done'' looks like.}
+exactly what ``done'' looks like.}