Bug Description
gem4gov app update-compliance and the onboarding flow both branch on the compliance regime, announce a regime-specific set of features that "are not yet authorized for <regime> and must be disabled", and then configure the engine identically.
Two things are the same across all three branches:
- The message. The 13 printed bullets are byte-identical for
FEDRAMP_HIGH, IL4 and IL5; only the regime name in the lead sentence changes.
- What is applied.
configure_gemini_enterprise_for_fedramp_high (:1526), configure_gemini_enterprise_for_il4 (:1642) and configure_gemini_enterprise_for_il5 (:1754) each load the same file and send its map unchanged:
yaml_path = os.path.join(script_dir, 'engine_features.yaml')
with open(yaml_path, 'r') as f:
engine_features = yaml.safe_load(f)
...
engine_patch_body = { "features": engine_features.get('features'), ... }
There is one engine_features.yaml in the package, and it carries no regime dimension. So the engine's feature posture — including the four disable-* keys — is identical whichever regime the operator picks.
The assistant PATCH in the same functions does diverge by regime (FedRAMP High's updateMask includes customerPolicy; IL5's does not), which shows per-regime behavior is intended somewhere. That is what makes the identical engine feature set look unintended rather than deliberate.
Environment and Deployment Context
- Stellar Engine Version/Commit:
v3.0.0 (f64ce6cd).
- Deployment Type:
- **FAST Stage (if applicable):
Steps to Reproduce
- Run
gem4gov app update-compliance --project-id <project> --engine-id <engine-a> --compliance-regime FEDRAMP_HIGH.
- Run the same command against a second engine with
--compliance-regime IL5.
GET both engines and diff their features maps.
Expected Behavior
Either each regime applies the feature set its own on-screen list describes, or — if the three regimes genuinely share one engine feature set — the tool says so once instead of naming a regime it did not act on.
Actual Behavior
The features maps are identical. Three regime choices produce one posture, announced three different ways.
Relevant Logs and Errors
None. Both runs report success.
Additional Context
The practical impact is that an operator deploying at IL5 is told a specific set of features is being disabled for IL5, and has no way to tell from the tool that the set applied is the FedRAMP High one.
If the sets should differ, this is a missing per-regime capability. If they should not, the messaging asserts a determination the code never makes. Either way the tool's output and its behavior disagree, and an auditor reading the transcript would conclude something the deployment cannot evidence.
Bug Description
gem4gov app update-complianceand the onboarding flow both branch on the compliance regime, announce a regime-specific set of features that "are not yet authorized for<regime>and must be disabled", and then configure the engine identically.Two things are the same across all three branches:
FEDRAMP_HIGH,IL4andIL5; only the regime name in the lead sentence changes.configure_gemini_enterprise_for_fedramp_high(:1526),configure_gemini_enterprise_for_il4(:1642) andconfigure_gemini_enterprise_for_il5(:1754) each load the same file and send its map unchanged:There is one
engine_features.yamlin the package, and it carries no regime dimension. So the engine's feature posture — including the fourdisable-*keys — is identical whichever regime the operator picks.The assistant PATCH in the same functions does diverge by regime (FedRAMP High's
updateMaskincludescustomerPolicy; IL5's does not), which shows per-regime behavior is intended somewhere. That is what makes the identical engine feature set look unintended rather than deliberate.Environment and Deployment Context
v3.0.0(f64ce6cd).Steps to Reproduce
gem4gov app update-compliance --project-id <project> --engine-id <engine-a> --compliance-regime FEDRAMP_HIGH.--compliance-regime IL5.GETboth engines and diff theirfeaturesmaps.Expected Behavior
Either each regime applies the feature set its own on-screen list describes, or — if the three regimes genuinely share one engine feature set — the tool says so once instead of naming a regime it did not act on.
Actual Behavior
The
featuresmaps are identical. Three regime choices produce one posture, announced three different ways.Relevant Logs and Errors
None. Both runs report success.
Additional Context
The practical impact is that an operator deploying at IL5 is told a specific set of features is being disabled for IL5, and has no way to tell from the tool that the set applied is the FedRAMP High one.
If the sets should differ, this is a missing per-regime capability. If they should not, the messaging asserts a determination the code never makes. Either way the tool's output and its behavior disagree, and an auditor reading the transcript would conclude something the deployment cannot evidence.