Skip to content

[Bug] gem4gov-cli: the compliance regime has no effect on the engine's feature posture — FedRAMP High, IL4 and IL5 print the same list and apply the same engine_features.yaml #190

Description

@JohnHales

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:
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Medium
    • FedRAMP High
    • FedRAMP Moderate
    • DoD IL4
    • DoD IL5
    • Stand-alone / Custom
  • **FAST Stage (if applicable):
    • Stage 0 (Bootstrap)
    • Stage 1 (Resource Management)
    • Stage 2 (Networking)
    • Stage 3 (Security)

Steps to Reproduce

  1. Run gem4gov app update-compliance --project-id <project> --engine-id <engine-a> --compliance-regime FEDRAMP_HIGH.
  2. Run the same command against a second engine with --compliance-regime IL5.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions