The bundle and package catalogue

B2 to B5, B7, B12 and B13 are written by one component each, and each is a bundle of related families. None of them needs the package transport, and none needs a coordinator. They need one transaction over the tables the document names, opened where the write begins and committed after the last row. B1 is single-owner as well, and one operation names its families, but they share no invariant. It is a bundle by that operation only: the import could apply the set as one, no operation declares all-or-nothing today, and the finding stays per family.

B7 and B12 already do this, so the pattern is proven in the codebase. B13 shows the cost of not doing it: the batch is saved, and the workunits are saved one at a time, so a failure leaves a batch whose work is partly dispatched. B1 to B5 show a second cost: the document reads back with whatever writes happened to succeed, because each repository call commits on its own.

B6 is also single-owner, and needs the same one transaction. It has no operation today, which is why it is absent rather than broken.

B9, B10, B11, B14, B17, B18, B19, B20 and B21 span several owners, or carry parts owned by another component, so each is a package. They cannot be one transaction, and the code does not try. Several of them already use a workflow run, and B21 adds a compensation that deletes what the step wrote.

The shape they need is the one Transporting a package describes: a manifest that names the bundles and their parts, one message per bundle which is one per owner, and a declared failure policy. B17 uses the workflow and states stop deliberately, because a provisioning run is resumed rather than undone. B14 uses the workflow and states no policy, which is why its atomic flag has nothing behind it.

B10 and B11 are the same set seen twice. The workflow gathers, the manifest row records, and the packaging step turns the parts into one file. That is the package classification implemented without its transport, and it earns its place because the ORE engine needs every part at one instant: the bundles are dispatched at one as_of, and the package is not atomic across them.

B1 to B5 and B8 share one fault: a file's element list became a type. The conventions document carries one array per convention kind because ORE XML lists those kinds, not because a zero convention constrains a CDS convention. The curve document repeats the shape for the curve file's element list. The analytics and reporting documents repeat the shape at smaller size, and the ORE import repeats it across messages instead of inside one struct.

The right shape for each is the one its owner count states. B1 has no cross-family invariant, so it is one family after another, each with its lists, converted on its own. B2 to B5 have a header that the children name, so each is one bundle per document with one transaction. B8 is one bundle per trade.

B14 is wrongly shaped in a different way: it declares an atomic flag on the request and ignores it. A caller can ask for all-or-nothing and receive a partial publication that reports success.

• B9, the environment export. The transport page works the example in full, and no export operation, manifest or part format exists in any header. The package classification has a transport page and no implementation.
• B18, sandbox promotion. The sandbox exists, the import targets it, and the promotion the transport page relies on does not. The compensating control the package design assumes is therefore not available.
• B19, the support package, and B20, the archival export. Neither is modelled. The only archive machinery is a generic tar.gz helper with no digest, no manifest and no part boundary, so neither can be built from it without the package work.
• The manifest, part and ledger types. No package_format_version, no bundle_record, no part_record, no part-apply ledger and no as_of field exists in the code. B11's row is the nearest thing, and it carries the storage keys and the counts.

• B1 and the documents like it are gathered only because a file contains them. The relatedness the classification asks for cannot be written without naming ORE XML. They are a package's contents: B1 is a bundle only because one operation names it, its families share no invariant, and no operation declares the import all-or-nothing, so each family is applied on its own. Declare that operation all-or-nothing and the bundle is atomic in refdata's unit_of_work; until then the finding stands.
• B14's atomic flag. The request promises a property the workflow cannot provide, and no code reads the field. A flag that nothing consumes is worse than no flag, because a caller believes it.
• B8's parts. A trade is priceable only when its instruments and legs exist, and the import writes them across many calls. The invariant is real and unenforced, so a failed import leaves a trade whose parts are missing. The compensation deletes the trade, which is why the failure is survivable and not why it is correct.
• B13's batch. "The batch is complete when every workunit has a canonical result" is the stated invariant, and the batch row and its workunits are written separately. A restart can leave an open batch with fewer workunits than the request named.