Inspect jobs across Rhythm services

Purpose

Combine compatible job records from different services into the same operational view.

How It Works

Each service publishes the same three compatible views of its job records. Platform discovers those views and reads them alongside its own families. Lists and pagination use one order across the discovered services. A job’s owning service supplies its subject and publishes the step definition in history. Platform can therefore present the job without installing its workflow implementation. Caller scope still restricts every read. Incomplete view contracts are excluded from discovery. New publishers become visible when a fresh process refreshes discovery.

Relationships

The job record supports reconciliation, notices and both monitors; owning modules retain responsibility for the work itself.

Show evidence (sources, provenance, origins, pinned commits)

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes: Published services’ jobs participate in shared monitoring.Subjects retain wording supplied by the owning service.
Surfaces: apijob
Preconditions: The publishing service exposes all three compatible views and required columns.
Postconditions: Published jobs remain readable and pageable in Platform without Platform changing them.
Constraints: Published views execute with the caller’s database privileges and remain subject to their row policies.

Controls

30 controls apply, from the corpus control catalogue.

TC-AVL-001 TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-006 TC-CHG-001 TC-CHG-002 TC-CHG-003 TC-CHG-004 TC-CHG-005 TC-CHG-006 TC-CHG-007 TC-IAM-001 TC-IAM-006 TC-LOG-002 TC-LOG-003 TC-LOG-005 TC-MON-001 TC-PI-001 TC-PI-002 TC-PI-004 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Business Rules

7 rules, 6 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

Id	Rule	Kind	Enforced at	Provenance
`01`must prove Proposed	Services publish compatible job, step and event views that Platform combines into shared list, count, snapshot and pagination results. proved by `ATS-PFM-OPS-007-01`, `ATS-PFM-OPS-007-08`, `TST-PFM-OPS-074`	policy	database, service	test services-platform:modules/jobs/tests/integration/services/snapshots/cross-service-jobs.integration.spec.js#pages across the two macroservices, the cursor of one continuing into the other
`02`must prove Proposed	Schema discovery excludes a service missing any required view or contract column. proved by `ATS-PFM-OPS-007-02`, `TST-PFM-OPS-074`	validation	service	test services-platform:modules/jobs/tests/integration/services/snapshots/cross-service-jobs.integration.spec.js#does not find a schema that holds the same job and publishes no view
`03`must prove Proposed	Platform reads another service’s jobs without changing them and applies the same caller scope and published step-definition rules. proved by `ATS-PFM-OPS-007-03`, `ATS-PFM-OPS-007-07`, `TST-PFM-OPS-074`	policy	service	test services-platform:modules/jobs/tests/integration/services/snapshots/cross-service-jobs.integration.spec.js#applies the caller’s scope to it, as to a job of Platform’s own
`04`must prove Proposed	Job subjects use wording published by the owning service, and monthly snapshot subjects include the month inside a workspace but omit it across workspaces. proved by `ATS-PFM-OPS-007-04`, `TST-PFM-OPS-066`	calculation	service, database	test services-platform:modules/jobs/tests/e2e/jobs-tenant-runs.e2e.spec.js#names the snapshot run by its snapshot alone when the list is read across tenants
`05`must prove Proposed	A shared catalog supplies job labels and application names, with an unknown kind receiving a readable fallback based on its identifier and service schema. proved by `ATS-PFM-OPS-007-05`, `TST-PFM-OPS-078`	calculation	service	test services-platform:modules/jobs/tests/unit/job-kind-labels.spec.js#humanises an unknown kind and attributes it to the application of its schema
`06`must prove Proposed	Registered Platform kinds must be represented in current job views and labeling coverage, with tests checking the view definition against its latest migration. proved by `ATS-PFM-OPS-007-06`, `TST-PFM-OPS-076`	invariant	service, database	test services-platform:modules/jobs/tests/unit/cross-job-query.view.spec.js#registers exactly the Platform job kinds, so none is invisible to the reconciler
`07` Proposed	A process caches discovery of publishing services, so newly published views become visible when a fresh Platform process discovers them.	policy	service	documented services-platform:docs/jobs.md#Every macroservice's jobs in one list (the cross-service contract, 2026-10-12)

Scenarios

Id	Given	When	Then	Provenance
`01`	A service publishes a merge job while Platform publishes another run for the same workspace.	The workspace’s jobs are listed.	Both jobs appear together with the merge subject supplied by its owning service.	inferred services-platform:modules/jobs/tests/integration/services/snapshots/cross-service-jobs.integration.spec.js#names the job in the owning macroservice’s own words, which is its subject

Edge Cases

Id	Given	When	Then	Provenance
`02`	A published kind has no entry in the label catalog.	Platform includes it in a job list.	Its readable fallback name and service application are returned.	inferred services-platform:modules/jobs/tests/unit/job-kind-labels.spec.js#humanises an unknown kind and attributes it to the application of its schema

Planning

Implementation

Inspect jobs across Rhythm services ​

Purpose ​

How It Works ​

Relationships ​