What should a provisioning call hand back so an automated case can prove which records it created?

Ask a provisioning seam for an account and you get an account. Ask what else appeared in the store while it was doing that, and most suites cannot tell you. Recording ownership at the moment of creation is a small design decision with a long tail: it is the difference between a shared target you can reason about and one where every unexplained record is somebody's guess. ## Creating one thing creates several A single provisioning request rarely produces a single record. Creating an account may also produce a profile row, a default preference set, an audit entry, a search index document and an outbound welcome record. If the seam returns only the account identifier, everything else is orphaned at birth — present in the store, attributable to nothing. That matters in three practical situations: - **The case wants to assert on a collateral.** It cannot refer to a record it was never told about, so it either re-queries the store by guesswork or asserts on the account and hopes. - **Somebody asks who created this.** Weeks later, on a target several runs share, an unexplained record is either a leak, a product defect or ordinary traffic. Without attribution the three are indistinguishable. - **A run has to account for itself.** A run that cannot enumerate what it created cannot report it, cannot hand it to any downstream policy, and cannot answer whether it grew the target. ## What a handle carries | Returned value | What the case can do | What a later reader can answer | | --- | --- | --- | | A bare identifier | Refer to the one record it asked for | Nothing about anything else created | | Identifier plus collaterals | Refer to and assert on everything created | Which records belong together | | Handle with a correlation tag | The above, plus name itself as the owner | Which case, which run, which worker created each record | The correlation tag is the cheap part and the valuable part. Three fields do most of the work: the case name, a run identifier, and the parallel test worker index. The case name says which behaviour produced the record; the run identifier says which execution; the worker index is what makes an interleaved, parallel run readable at all. ## Making the tag survive A tag that lives only in the runner's memory is gone the moment the process exits, which is exactly when the questions start. Ownership has to be recorded somewhere that outlives the run. Two placements, usually combined: 1. **In the record itself**, where the product's data model has room for it — a naming convention on a field the case controls, an address-style value carrying the run identifier, a metadata field the product exposes. Durable, queryable from the target, and it survives even a run that crashed before writing anything of its own. 2. **In a manifest the run emits**, appended to as each handle is issued and written out alongside the run's other artefacts. Complete and structured, but only as good as the run's ability to finish writing it, which is why an append-as-you-go manifest beats one assembled at the end. ## The manifest A manifest is an ordinary artefact: one entry per provisioning call, each naming what was created, when, by which case and run. It is worth keeping boring — a flat list of records with their kinds and identities — because its whole value is that anyone can read it without knowing the suite. What it buys is attribution after the fact. When a shared target starts behaving oddly, the manifest turns a forensic exercise into a lookup. When a provisioning path leaks records, the manifest shows which one and how fast. And when someone claims the suite is filling the target, the manifest either supports or refutes them with a count. ## Where ownership stops Recording ownership is deliberately separate from deciding what to do with what you own. The seam's job is to make the question answerable: these records exist, this case made them, at this time. What policy consumes that record is a different decision, and coupling the two is how a seam grows into something nobody can reimplement. There is also a boundary on what to claim. A handle should carry records the case may need to refer to or account for. Side effects the product generates on its own schedule, and would generate for any real user, are the product's business rather than the case's. The practical test is whether a later reader would need to attribute the record to a case at all; if the product produces it during ordinary use, it usually fails that test. ## The habit that makes it work Uniformity. Ownership only pays off when every provisioning path returns a handle in the same shape, because a manifest with holes has them exactly where the undisciplined path is — which, reliably, is the path that leaks.