Configuration Parameter Default Value Audit Prompt

This prompt is designed for platform engineers, DevOps practitioners, and SREs who need to verify that documented default values for configuration parameters match the actual behavior of a running system. The job-to-be-done is a parameter-by-parameter audit that catches incorrect defaults, missing required flags, undocumented environment variables, and stale deprecation warnings before they cause production misconfigurations. The ideal user has access to both the source of truth for documentation (a config reference page, a README, or a JSON schema) and the source of truth for implementation (source code, a live config endpoint, or a --help dump).

Use this prompt when you are preparing for a release, hardening a runbook, or onboarding a new service owner who needs to trust the docs. It is most effective when the scope is bounded—for example, a single microservice's configuration surface, a CLI tool's flags, or a Helm chart's values file. The prompt expects structured input pairs: each parameter's documented default and its observed or implemented default. It will flag mismatches, highlight parameters that are documented but not implemented (or vice versa), and note when a default is technically correct but semantically dangerous (e.g., an empty string that should be a sensible port number).

Do not use this prompt for runtime behavioral testing (e.g., whether a timeout value actually changes performance), for security-sensitive secret validation (secrets should never appear in prompt inputs), or for auditing configuration that is generated dynamically at deploy time by an operator or pipeline. The prompt is a static audit tool, not a dynamic configuration validator. For high-risk production systems, always pair the prompt's output with a human review step and, where possible, an automated test harness that diffs the documented schema against a live configuration dump. The next section provides the copy-ready prompt template you can adapt to your own config surface.

This prompt template is designed to audit documented configuration parameters—such as environment variables, config file keys, CLI flags, and API settings—against their actual default values in the target system. It accepts a structured input of documented parameters and returns a parameter-by-parameter audit report. The template uses square-bracket placeholders for all variable inputs, making it straightforward to adapt for different platforms, services, and documentation sources.

textCopy
You are auditing documented configuration parameters against actual system defaults.

## INPUT
[DOCUMENTED_PARAMETERS]

## CONTEXT
- System: [SYSTEM_NAME]
- Version: [SYSTEM_VERSION]
- Configuration source: [CONFIG_SOURCE_TYPE] (e.g., environment variables, YAML config, CLI flags, API settings)
- Audit scope: [AUDIT_SCOPE] (e.g., all parameters, security-critical only, recently changed)

## OUTPUT_SCHEMA
Return a JSON array of audit findings. Each finding object must include:
{
  "parameter_name": "string",
  "documented_default": "string or null",
  "actual_default": "string or null",
  "parameter_type": "string (env_var | config_key | cli_flag | api_setting)",
  "required": boolean,
  "deprecated": boolean,
  "deprecation_warning_documented": boolean,
  "finding_type": "string (incorrect_default | missing_required_flag | undocumented_env_var | stale_deprecation | correct)",
  "severity": "string (critical | high | medium | low | info)",
  "evidence_source": "string (how the actual default was determined)",
  "recommendation": "string (specific fix action)"
}

## CONSTRAINTS
- Flag parameters where documented_default differs from actual_default as "incorrect_default".
- Flag required parameters with no documented default as "missing_required_flag".
- Flag parameters present in the system but absent from documentation as "undocumented_env_var" (or appropriate type).
- Flag deprecated parameters whose documentation lacks deprecation warnings as "stale_deprecation".
- Mark correct parameters as "correct" with severity "info".
- If a parameter's actual default cannot be determined, set actual_default to null and note the limitation in evidence_source.
- Do not invent defaults. Only report what can be verified.

## EXAMPLES
[DOCUMENTED_PARAMETERS_EXAMPLE_INPUT]

Expected output:
[DOCUMENTED_PARAMETERS_EXAMPLE_OUTPUT]

## RISK_LEVEL
[RISK_LEVEL] (low | medium | high | critical)
- Low: Non-production development configs.
- Medium: Staging or internal tool configs.
- High: Production configs with security or reliability impact.
- Critical: Security-sensitive, compliance-relevant, or customer-facing defaults.

To adapt this template, replace each square-bracket placeholder with concrete values. For [DOCUMENTED_PARAMETERS], provide a structured list of parameters extracted from your documentation source—each entry should include the parameter name, documented default value, type, required status, and deprecation status. The [EXAMPLES] section is critical for few-shot behavior: include at least two representative input-output pairs showing correct handling of incorrect defaults, missing flags, undocumented variables, and stale deprecations. For high-risk or critical audit scopes, always route findings through human review before publishing corrections. Wire the output into a validation step that checks JSON structure compliance and severity classification consistency before the audit report reaches downstream consumers.

This prompt is designed to be integrated into a CI/CD pipeline or a scheduled documentation audit job, not run ad-hoc in a chat interface. The core workflow involves extracting documented defaults from your docs site or markdown files, extracting actual defaults from your application's configuration schema or a live introspection endpoint, and then feeding both structured inputs into the prompt for a row-by-row comparison. The prompt's value comes from its ability to reason about semantic equivalence (e.g., 300 vs "5m" for a duration) and to flag missing context like undocumented environment variables, which a simple diff tool would miss.

To wire this into an application, build a pre-processing step that normalizes both the documented configuration reference and the source of truth (e.g., a JSON Schema, a config.ts file, or the output of a --help command) into a consistent tabular format. Each row should represent a single parameter with fields for parameter_name, documented_default, actual_default, is_required, and deprecation_status. This normalized table becomes the [PARAMETER_TABLE] input for the prompt. After the model returns its audit report, a post-processing validator should parse the structured output (JSON is strongly recommended) and check for critical flags. For example, if the model flags a default as incorrect but the difference is a type coercion that is handled safely by the application, a human reviewer should be able to dismiss the finding. Log every audit run, including the input table, raw model output, and any human overrides, to build a history of configuration documentation accuracy over time.

For high-reliability environments, implement a two-pass validation. First, use a deterministic script to flag exact mismatches (e.g., string "true" vs boolean true). Second, use this LLM prompt to catch the semantic and contextual issues the script missed, such as a default value that is technically correct but dangerously permissive in production. Route findings flagged as risk: high or risk: critical to a review queue that requires human sign-off before the documentation can be published. Avoid using this prompt on its own for security-critical parameters like default admin passwords or exposed ports; those should be blocked by a hard linting rule in your CI pipeline before the LLM audit even runs.