cursus.steps.scripts.bedrock_prompt_template_generation

Bedrock Prompt Template Generation Script — declarative meta-prompt assembler.

Assembles the prompt-config bundle into ONE standardized prompts.json prompt ruleset in the {ruleset, rules} shape that BedrockProcessing / BedrockBatchProcessing consume — the SAME contract the knowledge-routing producer emits, so the two producers share one contract. The step’s job: validate the four config blanks -> assemble -> emit one prompt ruleset.

Design (a meta-prompt template with named slots + a validated input contract):

• ONE meta-prompt template with named slots ({SYSTEM_PROMPT} lives on ruleset.system_prompt; {RULES} / {INPUT_EVIDENCE} / {OUTPUT_CONSTRAINTS} on ruleset.user_prompt_template).

• The OUTPUT SCHEMA is embedded INSIDE the prompt (the {OUTPUT_CONSTRAINTS} block the model reads) AND carried as ruleset.output_schema (the machine half BedrockProcessing turns into the forced-tool schema). No separate validation_schema artifact is needed downstream.

• Assembly is a str.replace / str.join over the config bundle — NO tone register table, NO placeholder-example guessing, NO self-output prose validator (the removed ~1,200 LOC of ceremony; the fill-in-the-blank contract is enforced by the config Pydantic models at authoring time, not by re-validating the generated prose).

Container contract (bedrock_prompt_template_generation.step.yaml):

inputs prompt_configs=/opt/ml/processing/input/prompt_configs (OPTIONAL — bundled defaults) outputs prompt_templates=/opt/ml/processing/output/templates (the ONE prompts.json ruleset),

template_metadata=/opt/ml/processing/output/metadata,

env TEMPLATE_TASK_TYPE, TEMPLATE_STYLE, VALIDATION_LEVEL, INPUT_PLACEHOLDERS,

INCLUDE_EXAMPLES, TEMPLATE_VERSION

build_system_prompt(system_config, instruction_config)

Assemble the system layer from system_prompt.json — a deterministic join, no tone register.

Role + expertise + responsibilities + behavioral guidelines. (The former tone-adjustment table that rewrote the opener per ‘professional/casual/technical/formal’ register is removed — a classification-prompt generator does not need register switching.)

render_rule_block(rule, index, include_examples)

Render one rule as a fixed <RULE i> block.

Emits name + description + conditions + exclusions + key_elements (+ examples if enabled), each only when present — mirrors BedrockProcessing’s own _render_routed_rules block so the static-embed and the per-record-routed renderings are consistent.

render_rules_section(categories, include_examples)

Render all rules into the {RULES} slot, in priority order (lower priority number first).

render_input_evidence(input_placeholders)

Render the INPUT schema as labelled evidence slots the record fills (requirement #2, input).

build_output_constraints_text(output_format_config, category_names)

Render the OUTPUT SCHEMA as the prose block embedded IN the prompt (requirement #2, output).

This is the human-readable half of the schema — the exact fields, their descriptions, the category enum, and the validation rules — assembled from output_format.json (fed into the {OUTPUT_CONSTRAINTS} slot).

build_output_schema(output_format_config, category_names)

Build the machine output JSON schema (the forced-tool half), enum-locked to the rule names.

Precedence mirrors the former script: an explicit json_schema in output_format.json wins; a config that IS itself a JSON schema (has type) is used as-is; otherwise a schema is derived from required_fields + field_descriptions. The category field’s enum is always (re)populated with the rule names.

build_rules_list(categories)

Map category_definitions.json entries to the rules[] shape the Bedrock processing step reads: rule_name / description / conditions / exclusions / key_elements / priority_tier / abuse_flag / abuse_vector. (name->rule_name, exceptions->exclusions, key_indicators->key_elements, priority->priority_tier.)

assemble_prompt_ruleset(categories, system_config, output_format_config, instruction_config, input_placeholders, include_examples)

Assemble the ONE prompts.json prompt ruleset in the {ruleset, rules} contract.

ruleset.user_prompt_template embeds the rules + input evidence + OUTPUT SCHEMA inline via the META_PROMPT_TEMPLATE slots (requirement #2). ruleset.output_schema carries the machine schema. rules[] is the rule list. Identical downstream contract to the knowledge-routing producer.

load_config_from_json_file(config_path, config_name, default_config, log)

Load configuration from JSON file with fallback to defaults (merged over defaults).

load_category_definitions(prompt_configs_path, log)

Load category definitions (the rule list) from the prompt configs directory.

main(input_paths, output_paths, environ_vars, job_args, logger=None)

Assemble the config bundle into one prompts.json prompt ruleset.

Parameters:

• input_paths (Dict[str, str]) – {‘prompt_configs’: dir with system_prompt/category_definitions/output_format/instruction .json}

• output_paths (Dict[str, str]) – {‘prompt_templates’, ‘template_metadata’}

• environ_vars (Dict[str, str]) – TEMPLATE_*, INPUT_PLACEHOLDERS, INCLUDE_EXAMPLES, TEMPLATE_VERSION

• job_args (Namespace) – parsed CLI args

• logger (Callable[[str], None] | None) – optional logging function (defaults to print)

Returns:

A small summary dict (rules_assembled / output files).

Return type:

Dict[str, Any]