User Journey: Export for archival

"I want a copy of this party's data, as it stands today, that we can read back after the installation is gone." The journey is done when the person has a dated file set, a readable manifest, and a check that the files open in the platform's importer.

The actor is an operations user or tenant administrator. The trigger is a retention obligation, a migration off the installation, the end of a tenant, or an incident that asks for a point-in-time copy. The journey starts with a party and a date and ends when the archive is stored and the manifest signed off.

The platform has no archival export. The ORE export verbs produce ORE-shaped files, not a database archive. A PostgreSQL backup is the only complete copy, and it is taken outside the shell.

1. Fix the scope and the date. The person names the party and the cut-off. No export takes an as_of instant today, so the cut-off is the time the commands run, and the parts can be read minutes apart.
2. Export the trades. The person runs ore export once per portfolio or once for the whole tree. The output is ORE portfolio XML for the trades under each node.
3. Export the runs. The person runs ore export-run for every report definition that carries conventions, curves, today's market and pricing engines. A definition with no binding writes no configuration.
4. Export the market. The person runs marketdata export for the quotes and fixings.
5. Write the manifest. The person writes down the party, the time, each file, its size and the tool build. No command writes this.
6. Check the archive. The person opens the files in the platform's importer, or loads them into a scratch environment, and compares the counts with the live screens.
7. Store it. The person copies the set to the archive location, with the manifest, and records the archive id in the retention register.

The files parse, the counts match the live rows for the scope, and the manifest names every part. A later import of the set into a scratch environment reproduces the trades, the conventions and the market data.

An export of a node the session cannot read is refused or returns nothing. A run export refuses a binding whose configuration type it cannot write. A large portfolio is exported in pages, so a failure partway leaves a partial XML file that still parses. Nothing checks that the parts were read at the same instant.

• The ORE export must never be described as a full backup. It carries no audit columns, no row versions, no history and no party or book rights.
• An archive must never lose the difference between world conventions and the party's own. The export writes the party's document, and the world rows are added on import only if missing.
• A partial archive must never be signed off as complete. The manifest must name what was not exported.
• The archive must never depend on the source installation being alive.

There is no archive screen and no archive command. The entry points are ore export, ore export-run, marketdata export, the person's file system, and the retention register. The web UI has no export route.

1. No archival export. There is no command that writes one dated, complete set with a manifest and a checksum.
2. No history or audit in the export. The version and audit columns are not in any ORE-shaped file, so the archive cannot answer who changed what or when.
3. No instant. The exports read at their own times, so the set never existed together.
4. No verification. Nothing compares the archived counts with the live ones, or writes a digest the archive can be checked against.
5. No retention record. The product does not know an archive exists.

• Export to share with support - the small version of this export.
• Promote an environment between systems - the same parts, moved to another live environment.
• Reproduce a defect from an exported environment - the same parts, moved for a defect.
• Data exchange journeys - the group hub.

• Trade journeys
• Conventions journeys

• doc/knowledge/journeys/trades/journey_export_a_portfolio_to_ore.org