dirigent-examples 0.15.0__py3-none-any.whl

dirigent_examples/shelves/patterns/params-every-type.yaml

@@ -0,0 +1,259 @@
+# Every JSON Schema type a parameter can be, and the formats that actually assert.
+#
+# demo/params-showcase.yaml is about how parameters are PASSED -- flags, files, dotted keys,
+# coercion. This one is about what they are DECLARED as: the six types, the keywords that
+# constrain each of them, and the formats a dirigent instance genuinely checks rather than
+# merely annotates.
+#
+# The schema is plain JSON Schema, draft 2020-12, and it is load-bearing in three places: it
+# validates every run's parameters whoever started them, the UI renders the run dialog from
+# it, and apply checks every ${params.x} in the document against it so a typo is caught at
+# apply time rather than at 05:00.
+#
+# ABOUT format, AND THIS IS THE PART THAT SURPRISES PEOPLE. A format keyword asserts only
+# where the validator is given a checker for it. Parameter validation is not given one, so
+# every format below is an ANNOTATION: it documents intent and it is what the UI builds a date
+# picker from, and -p day=2026-13-40 is accepted. Types and bounds and enums and patterns all
+# assert; formats do not.
+#
+# Where they do assert is validate.schema, which is handed the instance's format checker --
+# the standard formats from the library (date, date-time, time, duration, email, uri, uuid,
+# ipv4, hostname, regex, json-pointer), the ones dirigent adds (ulid, uuid4, uuid7, md5, sha1,
+# sha256, sha512, base64), and whatever a plugin pack contributes, which is how a pack's
+# own format comes to be a format a pipeline can gate on. So a parameter that genuinely has to be a date
+# gets a gate, and this file has one: a pattern is the other answer, and it asserts in the
+# parameter schema itself.
+#
+# Every parameter below has a default, so the whole thing runs with no flags at all. That is
+# a property worth keeping in a corpus: an example nobody can run without reading the header
+# first is an example nobody runs.
+#
+# Hop by hop:
+#
+#   echo   one transform.jq step that pulls every parameter into one object, so the run's
+#          output is the resolved parameter set and the defaults are visible in it.
+#   gate   validate.schema against the schema this document carries, which is where the
+#          formats actually bite. With the defaults it passes and hands the value straight on.
+#   shape  proves the types survived: an integer is arithmetic, a boolean is a branch, and an
+#          array has a length. A parameter that arrived as text would fail here.
+#
+# EXPECT THIS RUN TO SUCCEED in about a second, with no network and no allowlist.
+#
+# To change it: -p day=2026-13-40 is ACCEPTED by the parameter schema and REFUSED by the gate,
+# which is the whole point of having both. params-validation-refuses.yaml is the other half:
+# what a request that fails the parameter schema itself is answered with.
+#
+#   dg run --local examples/patterns/params-every-type.yaml
+#   dg run --local examples/patterns/params-every-type.yaml -p day=2026-06-01 -p attempts=5
+#   dg run --local examples/patterns/params-every-type.yaml -p day=2026-13-40   # fails at the gate
+
+format: dirigent/v1
+kind: pipeline
+code: params-every-type
+name: Every parameter type
+description: |
+  The six JSON Schema types and the keywords that constrain each of them, with every
+  parameter carrying a default so the document runs bare.
+
+  A `format` in a parameter schema is an **annotation**: it documents intent and the UI
+  renders from it, and nothing checks it. Formats assert inside `validate.schema`, which is
+  handed the instance's checker -- so this document carries a schema and gates on it.
+
+tags: [patterns, transform, validate, params]
+
+# Carried in the document rather than named on an instance, so a --local run gates against
+# exactly the same shape a server would. A server refuses a document that carries a schema
+# this way for a pipeline it stores; a published example is where carrying one is right.
+schemas:
+  run-inputs:
+    type: object
+    required: [day, correlation_id, upload_id, expected_digest]
+    properties:
+      # The same four format keywords as in params below, in the one place they assert.
+      day: {type: string, format: date}
+      correlation_id: {type: string, format: uuid4}
+      upload_id: {type: string, format: ulid}
+      expected_digest: {type: string, format: sha256}
+
+requires:
+  blocks:
+    - transform.jq
+    - validate.schema
+
+params:
+  type: object
+  # Nothing is required, because everything has a default. required is for the parameter a
+  # run has no sensible value for -- the day being backfilled, the tenant being loaded.
+  additionalProperties: false
+  properties:
+    # A string, constrained by length and by pattern. The pattern is anchored, because an
+    # unanchored one matches anywhere in the value and refuses almost nothing.
+    dataset:
+      type: string
+      description: Which dataset this run covers.
+      default: climate
+      minLength: 1
+      maxLength: 64
+      pattern: "^[a-z][a-z0-9-]*$"
+
+    # An enum, which is a closed set rather than a type. The UI renders it as a select.
+    environment:
+      type: string
+      description: Where this run writes.
+      default: staging
+      enum: [staging, production]
+
+    # An integer with bounds, so a fat-fingered 1000 is refused rather than retried a
+    # thousand times.
+    attempts:
+      type: integer
+      description: How many times a downstream loader should try.
+      default: 3
+      minimum: 1
+      maximum: 10
+
+    # A number, which is any JSON number rather than a whole one. exclusiveMinimum is the
+    # keyword for a value that may approach zero and never reach it.
+    threshold:
+      type: number
+      description: The confidence a prediction has to clear.
+      default: 0.75
+      exclusiveMinimum: 0.0
+      maximum: 1.0
+
+    # A boolean, which the UI renders as a switch. Named for what true means, so nobody has
+    # to work out what a false "no_dry_run" would do.
+    dry_run:
+      type: boolean
+      description: When true nothing downstream writes.
+      default: true
+
+    # An array. items constrains every element, and the two bounds are what stop a fan-out
+    # over this from being either empty or enormous.
+    regions:
+      type: array
+      description: The regions this run covers.
+      default: [east, west]
+      minItems: 1
+      maxItems: 16
+      uniqueItems: true
+      items:
+        type: string
+        minLength: 1
+
+    # An object, with its own properties and its own closed door. A nested leaf is addressed
+    # from the CLI with a dotted key: -p window.days=30.
+    window:
+      type: object
+      description: The rolling window a load covers.
+      default: {days: 7, align: midnight}
+      additionalProperties: false
+      required: [days]
+      properties:
+        days:
+          type: integer
+          minimum: 1
+          maximum: 365
+        align:
+          type: string
+          enum: [midnight, hour]
+
+    # Formats, one line each. None of these asserts here; the gate below is what asserts.
+    day:
+      type: string
+      description: A calendar date, which the UI renders as a date picker.
+      default: "2026-01-01"
+      format: date
+
+    since:
+      type: string
+      description: An instant, offset included.
+      default: "2026-01-01T00:00:00+00:00"
+      format: date-time
+
+    cutoff:
+      type: string
+      description: A local time of day, with no date and no zone.
+      default: "23:30:00"
+      format: time
+
+    catalog_url:
+      type: string
+      description: Where the catalog is read from.
+      default: https://postman-echo.com/get
+      format: uri
+
+    owner_email:
+      type: string
+      description: Who to write to about this run.
+      default: data-team@example.org
+      format: email
+
+    correlation_id:
+      type: string
+      description: A UUID version 4 specifically; the plain uuid format would take any version.
+      default: 6f0b6e34-6c0e-4c2f-9a1e-2f43a1a0d0b7
+      format: uuid4
+
+    upload_id:
+      type: string
+      description: A Crockford base32 ULID, one of the formats dirigent contributes.
+      default: 01J8Z3M4N5P6Q7R8S9TVWXYZ01
+      format: ulid
+
+    expected_digest:
+      type: string
+      description: A sha256 hex digest, checked for length and alphabet rather than parsed.
+      default: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
+      format: sha256
+
+steps:
+  echo:
+    block: transform.jq
+    config:
+      input:
+        dataset: "${params.dataset}"
+        environment: "${params.environment}"
+        attempts: "${params.attempts}"
+        threshold: "${params.threshold}"
+        dry_run: "${params.dry_run}"
+        regions: "${params.regions}"
+        # A whole reference to an object resolves to the object, so the nested shape survives
+        # intact rather than being flattened into text.
+        window: "${params.window}"
+        day: "${params.day}"
+        since: "${params.since}"
+        cutoff: "${params.cutoff}"
+        catalog_url: "${params.catalog_url}"
+        owner_email: "${params.owner_email}"
+        correlation_id: "${params.correlation_id}"
+        upload_id: "${params.upload_id}"
+        expected_digest: "${params.expected_digest}"
+      program: |
+        .
+
+  gate:
+    block: validate.schema
+    depends_on: [echo]
+    # Where the formats bite. The gate is also a waypoint: everything below reads the gate's
+    # output rather than the echo's, so the document itself shows that nothing past this point
+    # saw an unchecked value.
+    config:
+      input: "${steps.echo.output.value}"
+      schema: run-inputs
+
+  shape:
+    block: transform.jq
+    depends_on: [gate]
+    # The proof that types survived the trip. Arithmetic on a string, or a branch on the text
+    # "false", would fail here rather than quietly doing the wrong thing.
+    config:
+      input: "${steps.gate.output.value}"
+      program: |
+        {
+          budget: (.attempts * .window.days),
+          confident: (.threshold > 0.5),
+          writes: (if .dry_run then "nothing" else .environment end),
+          regions: (.regions | length),
+          nested_leaf: .window.align
+        }

dirigent_examples/shelves/patterns/params-validation-refuses.yaml

@@ -0,0 +1,131 @@
+# What a bad run request is answered with, and how early the answer comes.
+#
+# Parameter validation is not a step. It happens when the RUN IS CREATED: defaults are filled
+# in, the schema is checked against the resolved object, and a request that does not satisfy
+# it is refused before a run row exists. So a bad request produces no run at all -- nothing to
+# find in dg runs list, nothing half-executed, no side effect anywhere. The error names the
+# location and says what was wrong with it:
+#
+#   parameter attempts is invalid: 99 is greater than the maximum of 10
+#   parameter tenant is invalid: '' should be non-empty
+#   parameter tenant is invalid: 'Nordic' does not match '^[a-z][a-z0-9-]*$'
+#
+# Each guard is worth having on purpose:
+#
+#   minimum/maximum    catches the fat-fingered order of magnitude.
+#   minLength/pattern  catches the value of the right type and the wrong shape.
+#   required           catches the parameter nobody can guess a default for.
+#   additionalProperties: false catches the TYPO, which is the one people forget. Without it,
+#                      regoins=[east] is accepted in silence, regions keeps its default, and
+#                      the run does the wrong work with a clean bill of health. The CLI
+#                      catches an unknown -p by name before it sends anything, naming what
+#                      the pipeline does declare; this keyword is what catches the same typo
+#                      arriving from the API, from a schedule's pinned params, or from a
+#                      webhook's mapped payload.
+#
+# WHAT IS NOT CHECKED HERE: format. A format keyword asserts only where the validator is given
+# a checker for it, and parameter validation is not given one -- so day below is documentation
+# and the UI's date picker, and -p day=2026-13-40 starts a run. A value that genuinely has to
+# be a date is gated with validate.schema, which IS handed the instance's format checker;
+# params-every-type.yaml carries that gate. A pattern is the other answer, and a pattern does
+# assert here.
+#
+# Defaults are filled in BEFORE validation, so a parameter with a default is optional and one
+# without a default and inside required is mandatory. There is no third state.
+#
+# Hop by hop:
+#
+#   plan     builds the load plan out of the validated parameters. If it runs at all, every
+#            value it reads has already satisfied the schema -- which is why no step in this
+#            file checks anything.
+#   receipt  posts the plan on, standing in for the work.
+#
+# EXPECT THIS RUN TO SUCCEED with the defaults, in about a second. The demonstration is the
+# runs that never start:
+#
+#   dg run --local examples/patterns/params-validation-refuses.yaml
+#   dg run --local examples/patterns/params-validation-refuses.yaml -p tenant=Nordic    # refused, pattern
+#   dg run --local examples/patterns/params-validation-refuses.yaml -p attempts=99      # refused
+#   dg run --local examples/patterns/params-validation-refuses.yaml -p regoins='["east"]'  # refused
+#   dg run --local examples/patterns/params-validation-refuses.yaml -p tenant=          # refused, minLength
+#
+# The same schema refuses the same values whoever is asking: the CLI, the API, a schedule's
+# pinned params, and a webhook's mapped payload all land in one validate call. That is what
+# makes a webhook safe to expose -- a caller cannot reach a parameter the mapping does not
+# name, and cannot get a value past the schema even for one it does.
+
+format: dirigent/v1
+kind: pipeline
+code: params-validation-refuses
+name: A run request that is refused
+description: |
+  Parameters are validated when the run is **created**, so a bad request produces no run at
+  all: nothing to find in `dg runs list`, and no side effect anywhere.
+
+  `format`, bounds, `required` and `additionalProperties: false` are four different guards.
+  The last one catches the typo, which is the one people forget.
+
+tags: [patterns, http, transform, params]
+
+requires:
+  blocks:
+    - transform.jq
+    - http.request
+
+params:
+  type: object
+  # The parameter nobody can guess for you. Everything else has a default, so this is the
+  # only one a run must supply -- and there is a default here too, so the example runs bare.
+  required: [tenant]
+  # The typo guard. Turning this off is how a run does the wrong work and reports success.
+  additionalProperties: false
+  properties:
+    tenant:
+      type: string
+      description: Whose data this run loads.
+      default: nordic
+      minLength: 1
+      maxLength: 32
+      pattern: "^[a-z][a-z0-9-]*$"
+    day:
+      type: string
+      description: The day being loaded. The format here documents and renders; it does not check.
+      default: "2026-01-01"
+      format: date
+    attempts:
+      type: integer
+      description: How many times the loader tries; bounded so a slip cannot mean ninety-nine.
+      default: 3
+      minimum: 1
+      maximum: 10
+    regions:
+      type: array
+      description: The regions to load. Misspell the name and the run is refused, not defaulted.
+      default: [east, west]
+      minItems: 1
+      items:
+        type: string
+
+steps:
+  plan:
+    block: transform.jq
+    # Nothing here re-checks anything. A step downstream of validation is entitled to assume
+    # the schema held, and a document that validates its own parameters again is a document
+    # whose schema was not doing its job.
+    config:
+      input:
+        tenant: "${params.tenant}"
+        day: "${params.day}"
+        attempts: "${params.attempts}"
+        regions: "${params.regions}"
+      program: |
+        {tenant, day, attempts, regions, work: ((.regions | length) * .attempts)}
+
+  receipt:
+    block: http.request
+    depends_on: [plan]
+    config:
+      url: https://postman-echo.com/post
+      method: POST
+      body:
+        plan: "${steps.plan.output.value}"

dirigent_examples/shelves/patterns/pipeline-run-child.yaml

@@ -0,0 +1,96 @@
+# The pipeline the four composition examples call, and an ordinary pipeline in every way.
+#
+# Nothing here says it is a child. It has its own code, its own parameter schema, its own run
+# history, and it can be run on its own, scheduled on its own, or called by four different
+# parents. Being callable is not something a document opts into.
+#
+# ITS PARAMETER SCHEMA IS THE INTERFACE. A parent writes these parameters out explicitly
+# rather than forwarding whatever it was run with, and they are validated against the schema
+# below when the parent's step executes -- not when the parent is applied. So a parent that
+# calls this with a region of 42 applies cleanly and fails at that step, which is why
+# additionalProperties: false and the bounds below are worth having.
+#
+# The status parameter exists for one of the parents. pipeline-run-strict.yaml needs a child
+# that settles completed_with_errors on purpose, and this is how: a tolerated failure, which
+# is a failed step whose dependents carry on and whose run is not clean.
+#
+# Hop by hop:
+#
+#   fetch     a tolerated call. Asked for 200 it succeeds and the run is green; asked for 500
+#             it settles failed and is tolerated, so the run ends completed_with_errors with
+#             the branch below it still running.
+#   summarise reads the parameters back into the small record a parent reads as this pipeline's
+#             answer. It runs either way, because a tolerated failure reads as a success to
+#             whatever depends on it.
+#
+# EXPECT THIS RUN TO SUCCEED on its defaults, in about a second:
+#
+#   dg run --local examples/patterns/pipeline-run-child.yaml -p region=east
+#   dg run --local examples/patterns/pipeline-run-child.yaml -p region=east -p status=500  # completed_with_errors
+#
+# Apply it before any of the parents; each of them names it in requires.pipelines, so a parent
+# applied to an instance without it is refused up front with the code to apply first.
+
+format: dirigent/v1
+kind: pipeline
+code: pipeline-run-child
+name: The called pipeline
+description: |
+  An ordinary pipeline that four composition examples call. Nothing about it declares that
+  it is a child; its parameter schema is the whole interface.
+
+  `-p status=500` makes it settle `completed_with_errors` on purpose, which is what
+  `pipeline-run-strict.yaml` needs something to do.
+
+tags: [patterns, http, transform, composition]
+
+requires:
+  blocks:
+    - http.request
+    - transform.jq
+
+params:
+  type: object
+  required: [region]
+  # A closed door, so a parent that misspells a parameter fails at the step with the reason
+  # rather than running with a default nobody chose.
+  additionalProperties: false
+  properties:
+    region:
+      type: string
+      description: Which region this run loads.
+      minLength: 1
+      maxLength: 32
+      pattern: "^[a-z][a-z0-9-]*$"
+    day:
+      type: string
+      format: date
+      description: The day being loaded.
+      default: "2026-01-01"
+    status:
+      type: integer
+      description: What the tolerated call is answered with; 500 settles this run completed_with_errors.
+      default: 200
+      enum: [200, 500]
+
+steps:
+  fetch:
+    block: http.request
+    # Tolerated: it settles failed, its dependents are shown a success, and the run reports
+    # completed_with_errors rather than failed. That third status is what strict is about.
+    continue_on_failure: true
+    config:
+      # A conditional written as data: the parameter picks the status, because the reference
+      # language has no branching construct and does not want one.
+      url: "https://postman-echo.com/status/${params.status}"
+      method: GET
+
+  summarise:
+    block: transform.jq
+    depends_on: [fetch]
+    config:
+      input:
+        region: "${params.region}"
+        day: "${params.day}"
+      program: |
+        {loaded: .region, day: .day}

dirigent_examples/shelves/patterns/pipeline-run-fire-and-forget.yaml

@@ -0,0 +1,99 @@
+# pipeline.run with wait: false -- start the child, hand back its run id, and move on.
+#
+# wait: false finishes the parent's step THE MOMENT THE CHILD RUN EXISTS. The step's output
+# carries the child's code and its run id, and a status of "started" -- which is not a claim
+# about how the child ended, because at that instant nothing knows.
+#
+# So this is a fork, not a call, and the consequences are worth being blunt about:
+#
+#   * The child's outcome never reaches this run. A child that fails leaves the parent green.
+#   * Nothing downstream of the step may assume the child's work happened. An edge below a
+#     fire-and-forget step orders itself against the child's CREATION and nothing else.
+#   * The run id in the output is the whole handoff. It is what an operator pastes into
+#     dg runs show, and what a notification carries, so that the fork is findable later.
+#
+# Use it for the branch nobody is waiting on: a notification, a cache warm, a downstream job
+# with its own alerting. Use wait: true whenever "and then" is part of the sentence.
+#
+# A third status is possible here and worth knowing about: skipped. If the child's own
+# concurrency policy refuses the run -- concurrency: skip on the child, with one already
+# going -- no child run is created, run_id is null, and the step reports skipped rather than
+# failing. A parent that assumes a run id is always there will read a null.
+#
+# Hop by hop:
+#
+#   waited     the child, called the ordinary way, so this file has one of each to compare.
+#   forked     the child again, not waited on. It finishes in milliseconds.
+#   handoff    reads both outputs side by side: one status is the child's real outcome, the
+#              other is "started".
+#
+# EXPECT THIS RUN TO SUCCEED in about three seconds, with waited's status succeeded and
+# forked's status started. In a --local run the throwaway instance goes away when the parent
+# settles, so a forked child may not get to finish -- which is the honest shape of the thing:
+# nobody is waiting for it.
+#
+#   dg run --local examples/patterns/pipeline-run-fire-and-forget.yaml \
+#     --also-apply examples/patterns/pipeline-run-child.yaml
+
+format: dirigent/v1
+kind: pipeline
+code: pipeline-run-fire-and-forget
+name: A parent that does not wait
+description: |
+  `wait: false` finishes the step as soon as the child run exists, reporting `started` and
+  the child's run id.
+
+  A fork, not a call: the child's outcome never reaches this run, and nothing downstream may
+  assume the child's work happened.
+
+tags: [patterns, pipeline, transform, composition]
+
+requires:
+  blocks:
+    - pipeline.run
+    - transform.jq
+  pipelines:
+    - pipeline-run-child
+
+params:
+  type: object
+  properties:
+    day:
+      type: string
+      format: date
+      default: "2026-01-01"
+
+steps:
+  waited:
+    block: pipeline.run
+    poll: 1s
+    config:
+      pipeline: pipeline-run-child
+      params:
+        region: east
+        day: "${params.day}"
+
+  forked:
+    block: pipeline.run
+    # No poll, because there is nothing to probe: the step is over as soon as the run row
+    # exists. A cadence here would be configuration that never fires.
+    config:
+      pipeline: pipeline-run-child
+      params:
+        region: west
+        day: "${params.day}"
+      # The one line this file is about.
+      wait: false
+
+  handoff:
+    block: transform.jq
+    depends_on: [waited, forked]
+    config:
+      input:
+        waited_status: "${steps.waited.output.status}"
+        forked_status: "${steps.forked.output.status}"
+        # The handoff. Without this in an output somewhere, a forked child is a run nobody
+        # can find on purpose.
+        forked_run: "${steps.forked.output.run_id}"
+      program: |
+        {waited_status, forked_status, forked_run, note: "started is not an outcome"}

dirigent_examples/shelves/patterns/pipeline-run-strict.yaml

@@ -0,0 +1,103 @@
+# strict: what a child that ended completed_with_errors does to the step that called it.
+#
+# completed_with_errors is a third run status, not a shade of failed: it means every step that
+# had to run ran, and at least one tolerated failure happened along the way. Whether that is
+# acceptable is a judgement the CALLER makes, not the child, because the same child called
+# from two places can be load-bearing in one and best-effort in the other. strict is where
+# that judgement is written down.
+#
+#   strict: false  (the default)  a child that ended completed_with_errors SUCCEEDS this step.
+#   strict: true                  it FAILS this step, exactly as a failed child would.
+#
+# A child that ended failed fails the step either way. strict only ever decides the middle
+# case.
+#
+# Both calls below ask the child for the same deliberate tolerated failure, so the child ends
+# completed_with_errors twice and the only difference is the flag.
+#
+# Hop by hop:
+#
+#   lenient  strict: false against a child that ends completed_with_errors. The step SUCCEEDS,
+#            and its output carries the child's real status -- so "succeeded" here is the
+#            step's outcome, not a claim about the child.
+#   strict   strict: true against the same thing. The step FAILS.
+#   verdict  all_done, so the run has an outcome to report whichever way the pair went. It
+#            reads only the lenient step's output: the strict one failed, so it has none.
+#
+# EXPECT THIS RUN TO FAIL, in about five seconds, with lenient succeeded, strict failed and
+# verdict succeeded. The failure is the demonstration.
+#
+# To change it: -p status=200 makes the child end cleanly and both calls go green, which is
+# the point -- strict costs nothing on a healthy child and is the difference between noticing
+# and not noticing on an unhealthy one.
+#
+#   dg run --local examples/patterns/pipeline-run-strict.yaml \
+#     --also-apply examples/patterns/pipeline-run-child.yaml                  # fails, by design
+#   dg run --local examples/patterns/pipeline-run-strict.yaml \
+#     --also-apply examples/patterns/pipeline-run-child.yaml -p status=200    # succeeds
+
+format: dirigent/v1
+kind: pipeline
+code: pipeline-run-strict
+name: Strict about a child's errors
+description: |
+  `completed_with_errors` is a third status, and whether it is acceptable is the caller's
+  judgement: `strict: false` (the default) passes it, `strict: true` fails the step on it.
+
+  A child that ended `failed` fails the step either way. As written the strict call fails
+  and the run reports `failed`.
+
+tags: [patterns, pipeline, transform, composition, failure]
+
+requires:
+  blocks:
+    - pipeline.run
+    - transform.jq
+  pipelines:
+    - pipeline-run-child
+
+params:
+  type: object
+  properties:
+    status:
+      type: integer
+      description: What the child's tolerated call is answered with; 500 makes it completed_with_errors.
+      default: 500
+      enum: [200, 500]
+
+steps:
+  lenient:
+    block: pipeline.run
+    poll: 1s
+    config:
+      pipeline: pipeline-run-child
+      params:
+        region: east
+        status: "${params.status}"
+      # The default, written out so the pair reads as two positions rather than one setting.
+      strict: false
+
+  strict:
+    block: pipeline.run
+    poll: 1s
+    config:
+      pipeline: pipeline-run-child
+      params:
+        region: west
+        status: "${params.status}"
+      # The one line this file is about.
+      strict: true
+
+  verdict:
+    block: transform.jq
+    depends_on: [lenient, strict]
+    # all_done, because the interesting run is the one where the strict call failed, and
+    # something still has to say what the pair amounted to.
+    rule: all_done
+    config:
+      input:
+        # Only the lenient step is read. The strict one failed, so it has no stored output,
+        # and a reference to it would settle this attempt as rejected.
+        child_status: "${steps.lenient.output.status}"
+      program: |
+        {child_status, note: "the same child status, two different step outcomes"}