Fix the controls before looking at products
Use the same definitions for flag identity, evaluation context, audience, change authority, fallback, audit record, and removal path. The accompanying feature-flag control sheet labels each answer as documented, observed, or unknown. A vendor page can fill only the documented column unless the evaluator has comparable access to test it.
Context needs particular care. A targeting or eligibility decision may be based on information about an operator, application, client, or request. Record the minimum fields, their source, and who is allowed to change them. Do not infer a privacy or authorization outcome merely because a flag product accepts context.
Require one equivalent exercise
In each authorised non-production environment, use the same synthetic workflow,
named change role, and—where policy separates approval—a distinct named
reviewer. Attempt and record the allowed or denied result for create, change,
approve, and retire. If a product does not expose one of those actions, label
that control unknown, not compliant.
Capture the key, context fields, intended audience, and visible result. Exercise
the documented fallback with a bounded test configuration or authorised
provider-unavailable simulation; record the expected safe/default behavior,
observed behavior, and recovery action. A distinct authorised operator must
then retrieve the actor, time, change, and audience evidence from the audit
record. When an exercise or retrieval is unavailable, record the observation as
unknown. If the products do not permit the same conditions, the comparison has
no common basis; record the ineligibility instead of inventing a score.
Keep this distinct from application rollback. A flag can alter behavior without being an application revision, and an application version history may not show who changed an audience rule or what happened when the flag service failed. See Evaluate Platform Promotion and Rollback Controls for that separate release-control boundary. For the separate evidence-retrieval question, see Evaluate an Internal-App Platform's Audit-Log Export.
Stop before an attractive dashboard becomes a conclusion
Do not publish a winner, a security conclusion, or a claim that an operational rollout is safe before every product has the same evidence threshold. A missing authorised role, plan, environment, or synthetic exercise is a finding about comparison eligibility, not an invitation to fill the gap from marketing copy.
This method is not a feature-flag implementation guide and does not prove a vendor's runtime behavior. It makes the evaluator's questions and limitations visible.
Does a detailed flag evaluation prove auditability?
No. Evaluation detail may describe a returned value. Auditability needs a separate, inspectable record of change, actor, time, and access under the evaluator's actual policy.
Can a feature flag replace a release process?
No. It may be part of an operational control set. The application revision, data effects, recovery owner, and deployment authority still need their own evidence.