In a case repository, a case references a shared step block. What is the difference between resolving that reference at authoring time and resolving it at execution time?
answer
- stencil versus live definition
- copied at insert, or assembled at render
- no pointer means no impact list
- reuse that decays was never reuse
- materialized when the run is generated
basics
~10 sAuthoring-time resolution copies the block into the case's own rows at save, so later edits never reach it. Execution-time resolution keeps a pointer and assembles the text each time the case is rendered.
solid answer
~50 sResolving at **authoring time** means the block is a template: inserting it copies its rows into the case, and from that instant the case owns them. Editing the block afterwards changes nothing the case shows, and the repository cannot tell you which cases came from it. Resolving at **execution time** means the case never owns the rows — it stores a pointer, and the step list is assembled when the case is opened or when a run is generated from it. Every reader sees the block as it reads now. Products with an explicit shared-step feature almost always take the second model, which is precisely why they show an impact list before you save an edit: with the first model there would be nothing to warn about. The practical question the model answers is whether a block edit can change what a tester is about to do mid-cycle.
go deeper
Know that inserting a block can mean copying its rows or storing a pointer, and that only the pointer version makes a later edit show up in cases already written.
Explain both models precisely and name what follows from each: whether a dependency index can exist, whether an impact list is computable, and whether cases drift apart over time.
Show you can determine which model a repository actually uses by experiment, and that you know the run-generation compromise that keeps a tester's list stable without giving up a live definition.
Own the policy for when an author picks copy over reference — chiefly cases that deliberately depend on old behaviour — and make sure the reason is recorded so nobody tidies it away later.
## The two timings A reference has to be turned into readable step text at some moment. Which moment it is determines everything else about reuse. **Authoring-time resolution.** Inserting the block is a one-off convenience. The repository copies the block's rows into the case at insert or save, and the case now owns them like any locally typed row. The block is a **template** or a stencil. Afterwards there is no relationship left: the block's edit history and the case's are separate stories, and the repository cannot enumerate which cases were stamped from which template because it never recorded that. **Execution-time resolution.** The case stores only the pointer. The step list is materialized at the moment somebody needs to follow it — when the case is opened for reading, or when a run is generated from it. The block's current text is what appears. The relationship is durable, which is what makes a dependency index possible at all. ## What each model changes | | Authoring-time | Execution-time | |---|---|---| | the block is | a stencil | a live definition | | a later edit to the block | reaches nothing | reaches every reader | | "which cases use this?" | unanswerable | a stored index | | impact list before a save | pointless, nothing to warn about | the whole point of the feature | | drift between cases | expected and invisible | prevented while pointers hold | | a tester mid-cycle | never sees the text change | can see it change under them | ## Why the distinction bites Three consequences follow, and each of them is where a team gets surprised: 1. **Whether an edit is a broadcast.** Under execution-time resolution, saving a block is an act with consequences for other people's cases. Under authoring-time resolution it is a private edit to a stencil, and the twenty cases already stamped from it stay exactly as they were — including the twenty copies of the mistake you just fixed. 2. **Whether reuse decays.** A stencil model looks like reuse on day one and is pure copying by day thirty: the cases stamped in March and the cases stamped in September no longer agree, and nothing surfaces the disagreement. This is the failure mode teams misdiagnose as "our shared steps do not work" when in fact they were never shared. 3. **Whether the step text is stable while somebody is following it.** Under execution-time resolution a block edit can land between a tester reading step three and reaching step four. Some products narrow this by materializing the step list when the run is generated rather than on every page render, which gives a tester a stable list for the duration without giving up the live definition in the repository. ## Reading which model you are on You rarely need documentation to tell — the behaviour is observable: - **Edit the block, reopen an old case.** Changed text means live resolution; unchanged text means the case owns its rows. - **Look for an impact list.** A product that names the affected cases before a save must be storing pointers, because it could not compute that list otherwise. - **Look for a usage view on the block itself.** A block that can tell you who references it is a live definition; a stencil has no idea who copied it. - **Diff two old cases that both used the block.** If they disagree in wording, they own their rows and were stamped at different times. ## Choosing, when the product gives you a choice Some repositories offer both — insert-as-copy and insert-as-reference — and then the choice belongs to the author. The useful test is whether a future correction to this action **should** reach this case. For a sign-in preamble the answer is almost always yes: if the sign-in journey changes, every case that signs in should change, and a case that quietly keeps the old journey is a case that will pass while doing the wrong thing. The answer is no when the case deliberately depends on the old behaviour — a compatibility case, a case pinned to a legacy client, a case whose whole point is the unmigrated path. Those cases should own their rows and say why in their own text, so that the next author does not re-point them at the shared block out of tidiness and silently delete the thing the case existed to check.
- Your repository resolves references live. What is the smallest change that stops a block edit landing under a tester who is halfway through following the steps?Materialize the step list once, when the run is generated from the case, rather than on every render. The repository keeps the live definition and the dependency index, but the tester follows a list that cannot move under them. It costs you the ability to push an urgent correction into a run already in flight.
- How would you demonstrate to a sceptical colleague which resolution model your repository uses, without reading any documentation?Make a throwaway block, reference it from a case, save, then change one word of the block and reopen the case. Changed text proves live resolution. As a second check, look for a usage view on the block: only a pointer-based model can list its referencing cases.
saying these in an interview costs you the question
- Assumes every product resolves shared steps the same way
- Thinks an insert-as-copy stencil still ripples on edit
- Cannot say why an impact list requires stored pointers
- Believes live resolution means text can never be stable during a run
- Calls stamped copies reuse without checking they still agree