Bulk Render Self-Disable Flag
Per PARITY_AUTONOMOUS_ROUTINE_PROMPTS_2026-05-17.md §Routine D stop condition.
Bulk render of universal commodity profile corpus is COMPLETE as of
2026-05-17T03:36Z. Final state: 331/331 full-profile commodities rendered
to entity_doc_projection + corresponding knowledge.domain='doc' rows.
The parity-bulk-render.yml cron workflow (in PR #794) MUST check for this
file’s existence on each fire and exit cleanly if present. The file
prevents the cron from re-seeding garbage or wasting GH Actions minutes
on an already-complete corpus.
How the 9,246 per-section rows are handled
knowledge.tenant_id='shared' AND domain='commodity' totals ~9,577 rows in
nathel-prod staging. Of these:
- 331 are full commodity profiles (have
content ? 'sections'jsonb key) — rendered - 9,246 are per-section knowledge fragments (e.g.,
acai_berry:s19_failure_modes) — NOT renderable as commodity profiles; belong to a different processing path (likely auto-vectorization for query_knowledge fallback)
The fix to parity-bulk-render.yml seed query (commit 4a444bbd on PR #794)
adds the content ? 'sections' filter so future cron fires don’t try to
render per-section rows.
How to remove this flag if bulk render needs to re-run
sha=$(gh api repos/fin-platform/fin-central-intranet/contents/docs/processes/bulk-render-complete.md --jq .sha)
gh api -X DELETE /repos/fin-platform/fin-central-intranet/contents/docs/processes/bulk-render-complete.md \
-f message="re-enable bulk render" -f sha="$sha"This would only be needed if:
- New commodity profiles get added to knowledge (count > 331)
- Renderer version bumps and existing docs need re-rendering at new version
- A migration changes the entity_doc_projection schema requiring re-population