request_ingestion

org.lexiara/lexiara · Verify this server

When a lookup returns `coverage` with `requestable: true`, ask for the missing instrument instead of stopping or guessing. Give the CELEX (or an EU ELI), the language and the version point; say WHY in one or two sentences; state any testable expectations. Lexiara validates the target, fetches the publisher's own bytes, reads them through the same parser and the same fail-closed checks every other act goes through, and returns handles you repeat your original lookup with. WHAT THIS TOOL IS NOT. It never fetches a URL you supply — the target must resolve to a publisher identifier this service derives itself, and `proposed_sources` is recorded as a note for a human and is never dereferenced. It states nothing about what the law means: acquiring an act makes the publisher's text addressable and does nothing else. EXPECTATIONS ARE HYPOTHESES, NOT INSTRUCTIONS. `has_article`, `has_annex`, `mentions` (three words or more), `min_provisions`, `language_is` are checked against the stored rows after publication and reported as matched, contradicted or not_verifiable. A contradicted expectation is reported and the publisher's text is left exactly as published — nothing is invented, translated or back-dated to satisfy one. Identical targets from different callers JOIN one acquisition; your rationale stays private to your account. Re-send the same `idempotency_key` to get the same request back rather than a second one. Jobs are asynchronous: read `retry_after`, then poll get_ingestion_request. This tool creates a request: an OAuth grant with only `read` cannot call it; reconnect and approve the explicit `ingestion:request` consent. Existing read grants remain read-only.