HoldFieldImprovementWorks
Controlled improvement, not automatic change
HoldField turns pilot evidence into reviewed, validated, rollback-safe improvement proposals — never automatic production changes.
Step 01
Pilot metric changed
A pilot metric changes enough to require human review — production behaviour is untouched.
Inputs
- Pilot metrics
- False-reject rate
- Escape candidates
- Coverage completeness
- Drift status
- Station health
Proof generated
- Metric-change receipt
- Trend snapshot
- Station context
- Time window
Where it appears in the app
- EvidenceWorks
- Review analytics
- Ops metrics
- AI Sense
AI Sense support
- Detects an unusual trend
- Explains its confidence
- Checks whether the evidence is complete
Safety boundary
- A metric change never alters production behaviour.
Step 02
False-reject candidate detected
A known-good or near-threshold case is flagged for analysis; sealed evidence is unchanged.
Inputs
- QA review
- Rule decision
- Evidence bundle
- Human decision
- Candidate history
Proof generated
- Candidate receipt
- Sealed evidence reference
- Review trail
- Reason code
Where it appears in the app
- Review
- Work packages
- EvidenceWorks
AI Sense support
- Finds repeated false-reject patterns
- Separates an evidence gap from a real rule issue
- Suggests human checks
Safety boundary
- False-reject analysis can never edit sealed evidence.
Step 03
Root-cause hypothesis
AI Sense forms a hypothesis, not a conclusion, with counter-evidence and missing proof.
Inputs
- Signals across evidence
- Reviews
- Drift
- Governance context
Proof generated
- Hypothesis receipt
- Supporting signals
- Missing-evidence list
- Confidence level
- Counter-evidence list
Where it appears in the app
- AI Sense
- Vision Twin knowledge
- Work packages
AI Sense support
- Links signals across evidence, reviews, drift, and governance
- Caps its confidence
- Shows the missing proof
Safety boundary
- A hypothesis is guidance only; it is never a production decision.
Step 04
Proposal drafted
A controlled proposal is drafted, not applied — it changes nothing by itself.
Inputs
- Candidate
- Hypothesis
- Affected stations
- Required evidence
Proof generated
- Proposal draft
- Expected impact
- Risk class
- Affected-station list
- Rollback requirement
Where it appears in the app
- Improvements
- Governance
- Commissioning
AI Sense support
- Prepares a draft summary
- Lists the required evidence
- Identifies affected stations
Safety boundary
- Drafting a proposal cannot change a station, model, PLC, route, or fixture.
Step 05
Impact & risk review
Risk and impact are reviewed before validation; review alone cannot authorize production use.
Inputs
- Proposal draft
- Affected stations
- Reviewer roles
- Risk policy
Proof generated
- Risk assessment
- Reviewer requirements
- Approval matrix
- Validation requirements
Where it appears in the app
- Governance
- Improvements
- AI Sense
AI Sense support
- Flags unsupported assumptions
- Shows missing risk proof
- Detects unsupported claims
Safety boundary
- Risk review cannot approve production use by itself.
Step 06
Shadow validation plan
The proposal must prove itself in shadow before production use; the live route is untouched.
Inputs
- Proposal
- Baseline window
- Station scope
- Acceptance thresholds
Proof generated
- Shadow validation plan
- Success criteria
- Rollback condition
- Customer-safe summary
Where it appears in the app
- Improvements
- Commissioning
- EvidenceWorks
AI Sense support
- Recommends validation checks
- Detects a missing sample size
- Prepares QA questions
Safety boundary
- Shadow validation never modifies the live production route.
Step 07
Customer review summary
The customer reviews the evidence and limitations; the report recommends, it does not approve.
Inputs
- Problem summary
- Proposal summary
- Evidence references
- Risk review
- Validation plan
Proof generated
- Customer-safe packet
- Omissions list
- Review receipt
Where it appears in the app
- SignalOps
- Trust
- Improvements
AI Sense support
- Summarizes the evidence
- Removes unsupported claims
- Highlights missing proof
Safety boundary
- The report recommends review; it never approves itself.
Step 08
Signed & rollback-safe gate
The gate records authorization once validated, signed, and rollback-safe — it does not command hardware.
Inputs
- Validated shadow result
- Risk acceptance
- Rollback plan
- Customer signoff where required
- HoldField signoff
Proof generated
- Approval receipt
- Rollback receipt
- Validation receipt
- Change-package reference
Where it appears in the app
- Governance
- Commissioning
- Improvements
- Ops metrics
AI Sense support
- Checks for missing approvals
- Flags expired evidence
- Detects rollback gaps
Safety boundary
- The gate records authorization; it does not command hardware or apply the change.
Customer-safe packet
Proof by reference, never raw data
The redacted packet carries a plain-English summary, references, receipts, risk, the shadow validation plan, and an explicit omissions list — never raw images, file paths, identities, tokens, PLC registers, or command payloads.
- problem_summary
- plain-English summary of what changed
- proposal_summary
- the proposed change (drafted, not applied)
- evidence_refs
- capsule + receipt references
- risk_summary
- risk class + reviewer requirements
- validation_plan
- shadow plan + success / rollback criteria
- known_limitations
- what the proposal does not claim
- rollback_plan
- owner, condition, deadline (references only)
- redaction_status
- redacted — no raw images or identities
- omissions
- explicit list of what was withheld
Signed-in teams run this operationally in the HoldField app, under Improvements — where a proposal is reviewed, validated in shadow, signed, and rollback-safe before any production use, and where the gate records authorization but never commands hardware. Open the workspace →