Draft, so high-level only. Overall shape is sound — BootstrapConfig as a single deployment-scoped config object is the right move once you have a second knob alongside policy, and the legacy-string fallback in parse_string_as_bootstrap_config makes the DB migration cleanly backwards-compatible.

Design things worth thinking through before this comes out of draft:

1. #[serde(flatten)] bootstrap_config: Option<BootstrapConfig> in ExtendedPipelineDescr / ExtendedPipelineDescrMonitoring is subtle — serde-flatten on an Option interacts awkwardly with utoipa OpenAPI generation and is hard to evolve (adding a third field later cannot be cleanly deprecated because flatten + Option hides which subset of fields was present in the JSON). Prefer either a non-Option BootstrapConfig with a Default sentinel, or accept the nested object explicitly in the JSON shape.

2. bootstrap_config_to_string does serde_json::to_string(&bootstrap).unwrap(). Fine in practice for a small Copy struct, but please add a one-line comment justifying the unwrap so a future contributor doesn't try to surface the error through call sites that can't return one. Also: the matching DBError::InvalidBootstrap(s) is now overloaded — 'unknown legacy string' and 'malformed JSON config' both reach it, and the operator-facing error message can't tell the user which case they hit. Worth splitting.

3. post_pipeline_approve used to record request.query_string() for the event tracker; the new code records "silent_bootstrap=true" or empty. Any future /approve query param will silently disappear from audit/event tracking. Reconstructing from the typed ApproveParameters (or keeping the raw string and additionally branching on the parsed value) would be more robust.

4. BootstrapConfig::from(p).with_silent_bootstrap(args.silent_bootstrap) is a bit awkward as a builder for a two-field Copy struct. A plain constructor BootstrapConfig::new(policy, silent_bootstrap) would let the three call sites in server.rs read top-to-bottom without the builder dance.

5. Cross-version compatibility: the PR description acknowledges that an old runtime binary started with --silent-bootstrap will fail. Please make sure that failure surfaces a useful error in the runner logs (clap's 'unexpected argument' message is fine if it's captured); otherwise the manager should pre-check the runtime version before passing the flag so users don't get a cryptic exit code.

6. Per workspace rule on enterprise/OSS divergence: test_bootstrap_enterprise is @enterprise_only and exercises the new additive silent_bootstrap knob — that's the right shape. When you finalize, please double-check no helper paths it touches behave differently between OSS and enterprise on existing endpoints.

Will do a full pass once it's out of draft.

What's the disadvantage of adding bootstrap configuration to the runtime configuration? It seems to be more about the behavior of the pipeline at runtime, rather than how to start it.

How does (silent) bootstrapping interact with fault tolerance? E.g., at-least-once fault tolerance or exactly-once fault tolerance?

Is silent bootstrapping not a feature to have always enabled? When does a user want to have intermittent output?

LGTM. Clean implementation: BootstrapConfig struct with backward-compatible DB parsing, well-documented silent_bootstrap semantics, thorough integration test covering multiple bootstrap cycles. The serde(flatten) on Option in PipelineSelectedInfoInternal is fine for backward compat but note that future BootstrapConfig fields will surface at the API top level.

Re-confirming approval after rebase. Single squashed commit 9c9ef57 carries the same design I already approved at 7aa10b6: BootstrapConfig with backward-compatible DB parsing, serde(flatten) on Option<BootstrapConfig> in PipelineSelectedInfoInternal, and the multi-cycle test_silent_bootstrap_enterprise covering transmitted_records=0 during silent bootstrap, normal resumption, and the non-silent final round. Docs in modifying.md are clear about when (not) to use silent bootstrap. No dbg!/eprintln! regressions; commit message is descriptive.

Prior non-blocking nits still stand (none are gating): bootstrap_config_to_string still uses .unwrap() with no justifying comment; DBError::InvalidBootstrap is now overloaded between legacy-string and malformed-JSON cases; post_pipeline_approve audit string is hard-coded to silent_bootstrap=true/empty rather than reconstructed from the typed query, so future /approve params will need to be added there explicitly. Worth picking up in a follow-up but not blocking.