PingOne DaVinci - Orchestrating Identity Flows

Discussion prompt

Before we open PingOne DaVinci - Orchestrating Identity Flows: without looking back, what was the main idea of Building a PingOne Protect Demo for Your Company, and what could you do by the end of it that you could not do before?

Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.

Discussion prompt

DaVinci's proposition is that this logic should be one diagram that executes, owned by the identity team, changed without a deployment.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Explain A flowchart that actually runs by analogy to something with no Identity & Access Management in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

Explain What DaVinci is, in Ping's own words to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Comparison matrix

From Connector vs connection vs capability: every row here is a choice with a cost. Fill the Analogy column, then say which row you would actually pick and what you give up for it.

Put in order

Put the moves of Reading a flow left to right into the order they have to happen.

1. Node 1: an HTTP connector with a Custom HTML Template capability shows the username and password form.
2. Node 2: a PingOne connector capability checks those credentials against the directory.
3. A logical operator on the connection between node 2 and node 3 decides the branch.
4. Node 3a on success: create a session and return. Node 3b on failure: an Error Message connector node.
5. Verify by walking the diagram and asking, at every line, "what makes this path get taken?"

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. User-facing nodes pause the flow and wait for input; backend nodes don't.

Discussion prompt

Work backwards. The example finished here:

Verify by walking the diagram and asking, at every line, "what makes this path get taken?"

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Predict first

A student writes this, and it looks reasonable:

The assumption: the canvas is live, so saving a flow updates what users get.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: The flow policy is pinned to a specific saved version, so your edit is sitting in a newer version nobody is routed to.

The model: editing a flow creates a version; the flow policy chooses which version runs.

Why: The flow policy is pinned to a specific saved version, so your edit is sitting in a newer version nobody is routed to.

Comparison matrix

From The vocabulary card: refill the One-line definition column from what you know. The rest of the table is as it appeared.

Eliminate the wrong options

You built and saved a flow, but calling your application still runs the old behavior. What is the most likely cause?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. The flow policy points at a pinned earlier version rather than Latest Version
• B. The flow needs to be exported and re-imported before changes take effect
• C. Connections cache their configuration and must be recreated after any flow edit
• D. Saving a flow only persists the canvas layout; node changes require a separate publish action

Survives elimination: A

Why: An application reaches a flow through a flow policy, and that policy names specific flows and versions — with Latest Version as an option. If the policy is pinned to an earlier version, new edits live in a version nothing routes to. This indirection is deliberate: it is what lets you edit safely while production keeps running a known-good build.

Check your understanding

You built and saved a flow, but calling your application still runs the old behavior. What is the most likely cause?

• A. The flow policy points at a pinned earlier version rather than Latest Version (correct)
• B. The flow needs to be exported and re-imported before changes take effect
• C. Connections cache their configuration and must be recreated after any flow edit
• D. Saving a flow only persists the canvas layout; node changes require a separate publish action

Answer: A

Why: An application reaches a flow through a flow policy, and that policy names specific flows and versions — with Latest Version as an option. If the policy is pinned to an earlier version, new edits live in a version nothing routes to. This indirection is deliberate: it is what lets you edit safely while production keeps running a known-good build.

Why B tempts people

Export and import exist for moving flows between environments, not for activating edits. Re-importing would create yet another flow and leave the original policy pointing wherever it already pointed.

Why C tempts people

Connections hold credentials and environment settings for a connector instance. They are independent of flow versions and do not need recreating when you edit a flow.

Why D tempts people

Saving persists the whole flow, not just layout. There is no separate publish step — the versioning and routing happen in the flow policy instead.

Match the pairs

From The HTTP connector earns its own slide — match each one to what it actually does. The descriptions have been shuffled.

• c1. Custom HTML Template
• c2. Custom HTML Message
• c3. Make REST API Call

• b1. Renders a full user-facing page you control. This is how forms, prompts, and branded screens get built.
• b2. A lighter message surface — the standard way to display errors while debugging.
• b3. Calls any external API from inside the flow, so anything with an endpoint can join the journey.

Why: Custom HTML Template, Custom HTML Message, Make REST API Call are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.

Put in order

These are the steps of Choosing a connector, scrambled. Put them back in order before the next slide shows you.

1. Does a Ping connector already do it? Use that — you get auth, retries, and error shapes for free.
2. Is there a service connector for the vendor? Use it rather than hand-rolling HTTP.
3. Does it need a user-facing page? HTTP connector, Custom HTML Template.
4. Is it a decision on data you already have? Functions connector.
5. Is it storing or reshaping a value? Variable connector.
6. Anything else with an endpoint? HTTP connector, Make REST API Call.

Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.

Predict first

Your flow must run against a development PingOne tenant in dev and a production tenant in prod, without redrawing the flow. What do you create?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: Two connections from the same PingOne connector, one per environment, and re-point the nodes

Why: A connector is the integration type; a connection is a configured instance of it with its own environment and settings. You can configure multiple instances of the same connector, which is precisely the mechanism for having dev and prod tenants without duplicating the flow. The diagram stays identical and only the connection binding changes.

Check your understanding

Your flow must run against a development PingOne tenant in dev and a production tenant in prod, without redrawing the flow. What do you create?

• A. Two connections from the same PingOne connector, one per environment, and re-point the nodes (correct)
• B. Two copies of the flow, one per environment, each with hardcoded environment IDs
• C. Two capabilities on the PingOne connector, selecting the appropriate one per node
• D. A single connection, switching its environment ID with a company variable at runtime

Answer: A

Why: A connector is the integration type; a connection is a configured instance of it with its own environment and settings. You can configure multiple instances of the same connector, which is precisely the mechanism for having dev and prod tenants without duplicating the flow. The diagram stays identical and only the connection binding changes.

Why B tempts people

Duplicating the flow doubles every future edit and guarantees the two copies drift. Environment differences are exactly what the connection abstraction exists to absorb.

Why C tempts people

Capabilities are the actions a connector exposes — create user, check password, and so on. They describe what a node does, not which tenant it talks to, so they cannot carry environment configuration.

Why D tempts people

Connection configuration is not driven by flow variables at runtime; credentials and environment settings live on the connection itself. This would also put production credentials one variable mistake away from being used in dev.

Discussion prompt

Creating your first flow — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: On the Flows tab, click Add Flow.

Draw it

Draw what Creating your first flow just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Predict first

Four ways to add a node, and they are not interchangeable — pick by what you want the canvas to look like afterwards.

Commit before you compute: what does Adding and wiring nodes come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Verify each new node has a meaningful Node Title on its Settings tab before moving on.

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. Ping's guidance is explicit about this, and an untitled node is a warning in Validate Flow.

Sort into buckets

These are the pieces of PingOne DaVinci - Orchestrating Identity Flows, out of order. Put each one back under the part of the lesson it belongs to.

The Mental Model

The problem DaVinci exists to solve; A flowchart that actually runs; What DaVinci is, in Ping's own words

Connectors: the Building Blocks

Four categories of connector; The five core connectors; The HTTP connector earns its own slide

Building a Flow

Creating your first flow; The three node types; Adding and wiring nodes

s1

The Mental Model is where PingOne DaVinci - Orchestrating Identity Flows puts The problem DaVinci exists to solve, A flowchart that actually runs, What DaVinci is, in Ping's own words. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s2

Connectors: the Building Blocks is where PingOne DaVinci - Orchestrating Identity Flows puts Four categories of connector, The five core connectors, The HTTP connector earns its own slide. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

s3

Building a Flow is where PingOne DaVinci - Orchestrating Identity Flows puts Creating your first flow, The three node types, Adding and wiring nodes. Knowing which part of the lesson a problem belongs to is most of knowing which method to reach for.

Put in order

Put the moves of A risk-based sign-on, node by node into the order they have to happen.

1. Node 1 — HTTP connector, Custom HTML Template: collect username and password.
2. Node 2 — PingOne Protect connector, Create Risk Evaluation.
3. Node 3 — PingOne connector: validate the credentials.
4. Wire three lines out of the risk node, branching on the returned risk level.
5. Node 4 — PingOne MFA connector on the medium branch.
6. Node 5 — PingOne Protect connector, Update Risk Evaluation, on every terminating branch.
7. Verify by running the flow once per branch and confirming each path terminates cleanly.

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Give every input element a unique ID; Ping's best practices call for this so you can reference the values later in the flow.

Predict first

A student writes this, and it looks reasonable:

The design: after a failed password, draw a line back to the first node to "try again."

It is wrong. Say what breaks — and say it before you turn the page.

Correct: Each pass re-executes those nodes, and each node can only run a limited number of times per invocation.

The design: one clear start, and retries as an explicit loop that does not re-enter it.

Why: Each pass re-executes those nodes, and each node can only run a limited number of times per invocation.

Check your understanding

A flow keeps taking the failure branch even though the credential check succeeds. Where should you look first?

• A. The logical operator configured on the connecting line out of the credential node (correct)
• B. The credential node's capability setting, since the branch is determined by which capability ran
• C. The flow policy, since branch selection is resolved by the policy at invocation time
• D. The application's OIDC configuration, which determines success and failure routing

Answer: A

Why: In DaVinci the branching condition lives on the connection between nodes, not inside the node. You right-click a connecting line to set its operator type, such as If All True or If Any False. When a flow takes an unexpected path, the line is where the decision was actually configured.

Why B tempts people

The capability determines what the node does — validating a credential, for example — but not which outgoing line is followed afterward. A node can have several outgoing lines with different conditions and only one capability.

Why C tempts people

A flow policy selects which flow and which version to run. Once execution starts, it has no involvement in branch-by-branch routing inside the flow.

Why D tempts people

OIDC configuration governs how the application and client exchange tokens at the boundary. It has no visibility into the internal branching of a flow.

Discussion prompt

Reaching into a nested value — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Write the variable reference in full braces first.

Sort into buckets

Sort these by Variables connector, from memory, without looking back at Who can create and update what. Telling them apart on the spot is the skill; the table is only where the answer happens to be written down.

Yes

Create flow instance variable; Update flow instance variable; Update user variable

No

Create user variable

g1

Variables connector is "Yes" for Create flow instance variable, Update flow instance variable, Update user variable — that is what the table on "Who can create and update what" records, and it is the single property separating this group from the rest.

g2

Variables connector is "No" for Create user variable — that is what the table on "Who can create and update what" records, and it is the single property separating this group from the rest.

Discussion prompt

The rule this trap just fixed:

The type is declared where the variable was created, and it is the thing that decides whether quotes are required.

Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?

Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.

Put in order

Put the moves of Passing data into a subflow into the order they have to happen.

1. Open the subflow and click Input Schema.
2. Use the variable name as the Parameter Name.
3. Select the Data Type matching the variable's type.
4. Enable Required if the flow cannot function without it.
5. Define the output schema the same way for values the parent flow needs back.
6. Verify by calling the subflow with a deliberately missing required parameter.

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. This declares what the subflow expects, which is also what makes it self-documenting to whoever calls it.

Predict first

A student writes this, and it looks reasonable:

The shortcut: clone a working node to make a similar one, then edit its settings.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: Those references point at the original node's ID, so the new node reads output produced somewhere else entirely.

The habit: after any clone or copy, verify the node IDs.

Why: Those references point at the original node's ID, so the new node reads output produced somewhere else entirely.

Put in order

These are the steps of Variable hygiene, scrambled. Put them back in order before the next slide shows you.

1. Pick the narrowest context that works — flow instance unless the value must outlive the run.
2. Declare user variables in the Variables tab before any flow writes to them.
3. Match names across subflow boundaries so parameter mapping is visually obvious.
4. Quote by declared type in Functions nodes; strings get quotes, numbers and booleans don't.
5. Verify node IDs after cloning with Show Node ID.
6. Echo a new reference into a debug message once before building logic on it.

Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.

Predict first

What is the difference between {{global.variables.orderId}} and {{global.flow.variables.orderId}}?

Commit to an answer, then rate it — certain, fairly sure, or guessing — and write the rating down before you turn the page.

Correct: The first is a flow instance variable scoped to a single execution; the second is a flow variable tied to the flow definition

Why: Flow instance variables are referenced as {{global.variables.variableName}} and hold values for one execution of the flow. Flow variables use {{global.flow.variables.variableName}} and belong to the flow definition rather than a single run. The near-identical syntax for very different lifetimes is exactly why this pair causes confusion.

The rating matters as much as the answer: confident-and-wrong is the combination that survives revision, because nothing about it feels like it needs revisiting.

Check your understanding

What is the difference between {{global.variables.orderId}} and {{global.flow.variables.orderId}}?

• A. The first is a flow instance variable scoped to a single execution; the second is a flow variable tied to the flow definition (correct)
• B. They are equivalent — the shorter form is an alias kept for backward compatibility
• C. The first is a company variable and the second is a user variable
• D. The first is read-only at runtime; the second can be updated by the variables connector

Answer: A

Why: Flow instance variables are referenced as {{global.variables.variableName}} and hold values for one execution of the flow. Flow variables use {{global.flow.variables.variableName}} and belong to the flow definition rather than a single run. The near-identical syntax for very different lifetimes is exactly why this pair causes confusion.

Why B tempts people

They are distinct contexts with distinct lifetimes, not aliases. Treating them as interchangeable produces the classic bug of a value that either vanishes between runs or persists when it should not.

Why C tempts people

Company variables are {{global.company.variables.name}} and user variables are {{global.userInfo.variables.name}}. Neither matches the two references in the question.

Why D tempts people

The variables connector can update flow instance variables, so the shorter form is certainly not read-only. Write access is not what separates these two contexts.

Discussion prompt

Creating an application and flow policy — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: On the Applications tab, click Add Application, then Edit…

Draw it

Draw what Creating an application and flow policy just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Comparison matrix

From Six ways to launch a flow: refill the Pick it when column from what you know. The rest of the table is as it appeared.

Predict first

Launching with the widget is about to be worked. State your hypothesis first: which rule or definition decides this one, and what is the first move it forces? Then watch whether the example agrees with you.

Correct: Your frontend asks your own backend for a DaVinci SDK token, which posts to /dvtoken.

Why: The token request is server-side precisely so the next point holds.

A hypothesis you wrote down is falsifiable; a vague sense of how it will go is not. If the example opens somewhere else, that gap is the thing worth chasing.

Annotate

Walk the callouts on Launching with the widget. Each one is a place this is easy to get subtly wrong.

• The token request is server-side precisely so the next point holds.
• Doing this in the browser publishes your API key to anyone who opens devtools. This is the one security rule of widget integration.
• The policy ID is the flow policy you configured — that's the link between the page and the journey.

Predict first

A student writes this, and it looks reasonable:

The order: design the journey, build every screen with Custom HTML Templates, then decide how the app calls it.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: SDK-launched flows accept only specific connector capabilities and need data-skbuttonvalue attributes on submit buttons.

The order: choose the launch method first, then build screens against its constraints.

Why: SDK-launched flows accept only specific connector capabilities and need data-skbuttonvalue attributes on submit buttons.

Discussion prompt

Run Deployment recipe with this step confiscated:

Set weights if you're A/B testing, and whitelist QA's IPs.

Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.

Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.

Discussion prompt

Deployment recipe works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".

Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.

Predict first

While creating a flow policy, which setting cannot be changed later and therefore needs a deliberate decision up front?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: The PingOne Flow Policy option, which must be enabled if you plan to launch the flow through a redirect

Why: The flow policy creation flow offers a PingOne Flow Policy option and the documentation notes it cannot be changed later. It is the setting that matters if you intend to launch the flow through a redirect, so getting it wrong means deleting the policy and creating it again.

Check your understanding

While creating a flow policy, which setting cannot be changed later and therefore needs a deliberate decision up front?

• A. The PingOne Flow Policy option, which must be enabled if you plan to launch the flow through a redirect (correct)
• B. The distribution weights, which are fixed once traffic has been served against them
• C. The Policy Name, which becomes the immutable identifier the application routes on
• D. The selected success nodes, since changing them would invalidate historical analytics

Answer: A

Why: The flow policy creation flow offers a PingOne Flow Policy option and the documentation notes it cannot be changed later. It is the setting that matters if you intend to launch the flow through a redirect, so getting it wrong means deleting the policy and creating it again.

Why B tempts people

Weights are explicitly meant to be adjusted — shifting them is how you ramp a new flow version from 10% to 100% of traffic. A fixed weight would defeat the purpose of A/B testing.

Why C tempts people

The policy name is a label you choose for readability. Nothing in the documented configuration steps marks it as immutable or as the routing identifier.

Why D tempts people

Success nodes are chosen for analytics measurement and are part of ordinary policy configuration. Nothing indicates they are locked after creation.

Comparison matrix

From Validate Flow — do this before anything else: every row here is a choice with a cost. Fill the Meaning column, then say which row you would actually pick and what you give up for it.

Discussion prompt

Reading Flow Analytics — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Open the flow and click Analytics in the lower left to open the…

Discussion prompt

Work backwards. The example finished here:

Verify against the two documented constraints before concluding data is missing.

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Comparison matrix

From The limits you must design around: refill the Value column from what you know. The rest of the table is as it appeared.

Discussion prompt

Explain Timeouts: the recommended band to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Predict first

A student writes this, and it looks reasonable:

The design: a polling loop that checks an external system until it returns ready.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: Each node can run a maximum of 20 times per flow invocation, so the 21st pass fails.

The design: bound every loop, and use the right tool for waiting.

Why: Each node can run a maximum of 20 times per flow invocation, so the 21st pass fails.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

DaVinci's proposition is that this logic should be one diagram that executes, owned by the identity team, changed without a deployment.; Every company already has these diagrams. They're in Confluence, they're six months stale, and the code drifted away from them.; DaVinci rarely stores your users or checks your passwords. It calls the things that do, in an order you drew, with branching you control.

Breaks

The assumption: the canvas is live, so saving a flow updates what users get.; The shortcut: a single PingOne connection, pointed at production, used by every flow.

sound

These are stated as this lesson states them — each one survives the edge cases PingOne DaVinci - Orchestrating Identity Flows puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Eliminate the wrong options

A node's output is consistently empty, but the flow runs with no errors and Validate Flow reports nothing. What is the most likely cause?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. A variable reference that fails to resolve — unresolved references yield an empty value rather than raising an error
• B. The flow exceeded the 20-execution-per-node limit, which silently empties subsequent node outputs
• C. Analytics retention expired, so the output exists but is no longer displayed
• D. The log level is set to Info, which suppresses node output values entirely

Survives elimination: A

Why: An unresolved variable reference — a typo in the context path, or a reference pointing at the wrong node ID after a clone — produces an empty value instead of an error. Nothing fails, so neither the run nor Validate Flow flags it. This is why echoing a new reference into a debug message before building logic on it is such a high-value habit.

Check your understanding

A node's output is consistently empty, but the flow runs with no errors and Validate Flow reports nothing. What is the most likely cause?

• A. A variable reference that fails to resolve — unresolved references yield an empty value rather than raising an error (correct)
• B. The flow exceeded the 20-execution-per-node limit, which silently empties subsequent node outputs
• C. Analytics retention expired, so the output exists but is no longer displayed
• D. The log level is set to Info, which suppresses node output values entirely

Answer: A

Why: An unresolved variable reference — a typo in the context path, or a reference pointing at the wrong node ID after a clone — produces an empty value instead of an error. Nothing fails, so neither the run nor Validate Flow flags it. This is why echoing a new reference into a debug message before building logic on it is such a high-value habit.

Why B tempts people

Exceeding the execution ceiling causes the flow to fail rather than quietly emptying outputs. It also would not be consistent across every run, since the limit is only reached on paths that loop.

Why C tempts people

Retention affects whether you can view a past execution in analytics after 30 days. It has no effect on what a node actually produces at runtime.

Why D tempts people

Log level changes how much detail is captured and which nodes highlight in analytics. It does not change node behavior, and Info is the normal production setting.

Discussion prompt

Explain DaVinci and Protect, in one sentence each by analogy to something with no Identity & Access Management in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

Outside this lesson: where does PingOne DaVinci - Orchestrating Identity Flows actually turn up? Name one concrete situation — a job, a piece of software someone ships, a decision somebody has to make — and say which part of Production readiness checklist is doing the work in it.

Hint: Vague is the failure mode here. "Engineering" is not a situation; "deciding whether this build is fast enough to ship" is.

Discussion prompt

The deck's JSON carries all entries with full URLs in its sources block.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Draw it

One page, no notation unless you need it: draw how these connect — The Mental Model · Connectors: the Building Blocks · Building a Flow · Variables and Subflows · Deploying a Flow · Debugging and Limits. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.