Skill: Production Control

Purpose

Define technical controls that ensure safe, observable, and auditable operation of the model in batch and service environments.

This skill turns governance into runtime behavior.

Inputs

Required IR fields:

model interfaces
deployment assumptions
risk tier output

Skill data inputs:

monitors.yaml (control patterns and snippets)

Outputs

Logging and lineage requirements
Monitoring hooks (input/output, drift, failures)
Audit artifacts
Code snippets or patterns for instrumentation

Rules

Evidence & uncertainty (non-negotiable)

Every materially non-trivial claim must be supported by evidence ids.
If a control requirement cannot be supported by evidence, mark Not evidenced and add an unknown stating what’s missing.

Control coverage (minimum set)

Controls must be implementable, not aspirational.
Distinguish batch vs service execution paths (mark not applicable explicitly).
Explicitly cover:
- input validation
- output validation / sanity checks
- lineage (inputs, parameters, versions)
- audit logging
- error handling (fail-fast vs fallback) and retry/timeout expectations
- access control assumptions (authn/authz boundaries) where evidenced
- operational runbook hooks (what on-call needs to know)
Prefer additive controls (wrappers/hooks/config flags) over invasive refactors.
Generated code must be realistic, minimal, and not change core model math unless explicitly part of remediation.

JSON / schema contract

Return JSON matching the schema exactly: no extra keys, no missing required keys.
Use explicit null/sentinel only where allowed by the schema.

System Prompt

You are designing production controls for a financial model. Assume this model will be scrutinized after an incident.

User Prompt Template

Given the model IR and risk tier:

Define required production controls.
Specify monitoring and logging expectations.
Provide example instrumentation code where appropriate.

Return JSON matching the schema exactly.

Post-run Checks

Controls are consistent with tier requirements.
Instrumentation code is coherent.

Rules

Every materially non-trivial claim must be supported by evidence ids.

If a control requirement cannot be supported by evidence, mark Not evidenced and add an unknown stating what’s missing.

Controls must be implementable, not aspirational.

Distinguish batch vs service execution paths (mark not applicable explicitly).

Explicitly cover:

input validation
output validation / sanity checks
lineage (inputs, parameters, versions)
audit logging
error handling (fail-fast vs fallback) and retry/timeout expectations
access control assumptions (authn/authz boundaries) where evidenced
operational runbook hooks (what on-call needs to know)

Prefer additive controls (wrappers/hooks/config flags) over invasive refactors.

Generated code must be realistic, minimal, and not change core model math unless explicitly part of remediation.

Return JSON matching the schema exactly: no extra keys, no missing required keys.

Use explicit null/sentinel only where allowed by the schema.

Skill: Production Control

Skill: Production Control

Purpose

Inputs

Outputs

Rules

Evidence & uncertainty (non-negotiable)

Control coverage (minimum set)

JSON / schema contract

System Prompt

User Prompt Template

Post-run Checks

Related Skills

Markdown Converter

Nano Banana Pro

1password

Skill: Production Control

Purpose

Inputs

Outputs

Rules

Evidence & uncertainty (non-negotiable)

Control coverage (minimum set)

JSON / schema contract

System Prompt

User Prompt Template

Post-run Checks