Skip to content

docs: how the cores feature works#1220

Open
paulalbert1 wants to merge 1 commit into
masterfrom
docs/cores-how-it-works
Open

docs: how the cores feature works#1220
paulalbert1 wants to merge 1 commit into
masterfrom
docs/cores-how-it-works

Conversation

@paulalbert1

Copy link
Copy Markdown
Contributor

Adds docs/cores.md — the single source of truth for the core-facility usage feature.

Covers:

  • Surfaces + their flags (public /cores index + per-core pages, pub-modal section, /edit/core review index + queue, admin toolbar tab).
  • Data pipeline end to end: ReciterAI batch_screenreciterai DynamoDB (PUB#/CORE#) → SPS etl:dynamodb Block 6 → SPS RDS → Prisma reads.
  • Status model: engine candidate/confirmed/below_threshold read-merged with human CoreClaim (claimed/rejected) → effective-confirmed.
  • The CORE_CATALOG FK guard (a core must be listed or its rows skip).
  • Running the engine: the recall-safe --drop-threshold 0.1 run (~$5, author∪MeSH pre-filter) and why MeSH-alone gating is unsafe.
  • The ETL + the manual workaround: the nightly aborts at the ED chain head (Staging Session B: populate data + build search index #443), so cores are projected via a standalone in-VPC etl:dynamodb run-task (exact command included).
  • Verification + per-env rollout steps + a key-files map.

Docs-only; reflects what shipped in #1216 (catalog→13) and #1219 (discoverability).

End-to-end reference for core-facility usage: the surfaces and their flags, the
ReciterAI batch_screen -> reciterai DynamoDB -> etl:dynamodb -> SPS RDS pipeline,
the candidate/confirmed status merge, the CORE_CATALOG FK guard, the recall-safe
~$5 engine run, and the standalone etl:dynamodb run-task workaround for the
ED-chain-head nightly abort (#443). Includes verification + per-env rollout steps.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant