The provision-parties workflow names two subjects that do not exist

Two pages name command subjects for the party-provisioning saga that do not exist:

• The header comment of projects/ores.refdata/api/include/ores.refdata.api/workflow/provision_parties_workflow.hpp:41-47 says step 0 publishes refdata.v1.parties.save and step 2 publishes iam.v1.account_parties.save.
• projects/ores.refdata/core/modeling/ores.refdata.protocol.org:64 lists refdata.v1.parties.save in its Parties table, and refdata.v1.parties.history on the line below, which is absent too.

The code uses different names. The definition's real step subjects are refdata.v1.parties.put (provision_parties_workflow.hpp:81), iam.v1.accounts.save (:134) and iam.v1.account_parties.put_many (:173). No nats_subject anywhere uses parties.save, account_parties.save or parties.history.

The refdata protocol page is where a reader learns which subjects the component serves, and the comment is where a reader learns what the saga does. Both send the reader to a subject no broker will route, and the mismatch already misled the journey architecture audit into recording the save names as the saga's steps.

• projects/ores.refdata/api/include/ores.refdata.api/workflow/provision_parties_workflow.hpp:41-47 — the comment; :81, :134, :173 — the three real subjects.
• projects/ores.refdata/core/modeling/ores.refdata.protocol.org:60-66 — the Parties table.
• projects/ores.refdata/api/include/ores.refdata.api/messaging/party_protocol.hpp:95-273 — the generated party subjects, which use put, put_many, delete and parties_versions.*.
• projects/ores.iam/api/include/ores.iam.api/messaging/account_party_protocol.hpp:69-201 — the generated account-party subjects, which use put and put_many.
• Audit the journey, provisioning and web-client architecture before the first implementation story — finding 2, corrected there on 2026-09-27.

• Party provisioning returns no workflow instance ids — the same saga's other defect.