Known-Good
Mode
You don't write the third-party software you run - and a vendor's lab is not your environment. Known-Good Mode pins every system to its verified known-good baseline and rolls back the moment behavior deviates from it. It validates against what "good" actually looks like in your estate, not against generic defaults.
What is known-good mode?
A known-good baseline is a verified, healthy reference state of a system - captured for your specific environment. It records how a system looks and behaves when it is working correctly in your estate, so it can serve as the truthful standard for every change that follows.
Known-Good Mode pins every system to its verified known-good baseline and rolls back the moment behavior deviates from it. It validates against what "good" actually looks like in your environment - not against a vendor's generic defaults.
You didn't write it. Prove it's good in your estate.
You don't write the third-party software you run - VMware, monitoring agents, applications, drivers. Vendors validate against their own labs and defaults - not your environment, your dependencies, your tribal knowledge. Vendor defaults are a starting point, not the truth of your environment.
Known-Good Mode validates third-party software and its changes against your established known-good baseline - so "works on the vendor's bench" becomes "proven good in your estate."
- Vendor Validates against its own lab and default configuration - a starting point, not your truth.
- Keystone Validates against your known-good baseline - your real dependencies, behavior, and tribal knowledge.
Two reference points. Only one is the truth of your estate.
A vendor default tells you how software is supposed to behave. Your known-good baseline tells you how it actually behaves in your environment - with your dependencies and the hard-won tribal knowledge your team has accumulated.
| Vendor Defaults | Your Known-Good Baseline | |
|---|---|---|
| Reference point | The vendor's lab | Your real estate |
| Accounts for your dependencies | No | Yes |
| Reflects your tribal knowledge | No | Yes |
| Catches environment-specific breakage | No | Yes |
| Rollback target | A generic default state | Your verified baseline |
Known-good, gate by gate
Known-Good Mode runs across Keystone's validation gates: Gate 1 captures and verifies your known-good baseline and backup, Gate 6 compares post-change behavior against it, and deviation triggers escalation or automatic rollback to the known-good state.
Baseline Capture & Verification
Captures and verifies the known-good baseline for your specific environment - and confirms a tested backup exists - so there is always a proven-healthy state to validate against and roll back to.
Behavioral Comparison (Block Stack)
Runs the change in a production-mirroring lower environment and compares post-change behavior against your known-good baseline - catching deviation before it reaches production.
Rollback to Known-Good
On deviation, escalates for review or automatically rolls the system back to its verified known-good state. Recovery targets your real baseline, not a generic default.
See how all eight gates work together in Change Validation.
Known-good mode, answered
What is a known-good baseline?
A known-good baseline is a verified, healthy reference state of a system - captured for your specific environment, not assembled from a vendor's generic defaults. It records how a system actually looks and behaves when it is working correctly in your estate: its configuration, dependencies, and observed behavior. Because it reflects your real environment, it becomes the truthful standard against which any future change can be measured. Known-Good Mode pins every system to its verified known-good baseline and rolls back the moment behavior deviates from it.
Why aren't vendor defaults enough?
You don't write the third-party software you run - VMware, monitoring agents, applications, drivers. Vendors validate that software against their own labs and default configurations, not against your environment, your dependencies, or the tribal knowledge your team has built up over years. Vendor defaults are a starting point, not the truth of your environment. A change that is "good" on the vendor's bench can still break in your estate, where it meets your specific configuration and dependencies. Validating against your own known-good baseline is what turns "works in the vendor's lab" into "proven good in your environment."
How does Keystone validate third-party software?
Known-Good Mode validates third-party software and its changes against your established known-good baseline - the verified state of that software in your environment. When a vendor update, agent change, or driver lands, Gate 6 (Block Stack) runs it in a production-mirroring lower environment and compares the resulting behavior against your baseline. Instead of trusting that the vendor's defaults are correct for you, Keystone proves the change still behaves the way "good" looks in your estate. "Works on the vendor's bench" becomes "proven good in your environment."
What happens when a system deviates from known-good?
Deviation is the signal that something is no longer in its verified-healthy state. When Keystone detects that post-change behavior has drifted from the known-good baseline, it escalates the change for review or - depending on policy - automatically rolls the system back to its verified known-good state. Because Gate 1 already captured and verified the baseline and a tested backup, the rollback target is your real environment, not a generic default. The system returns to a state that is known to be good, fast, before the deviation can spread to production.
Validate against your estate, not a vendor's lab
Known-Good Mode is one capability of AuthorityGate Keystone. Join the invitation-only Founding Members Early Access Program and prove every third-party change is good in your environment before it ships.