Date readers infer exact days from timestamps without source precision
The 10.0 legacy relation readers still render flattened timestamps without source precision/calendar metadata. root/wander-train/reach_router_v1.py::show_time is unchanged from 4.9: given 1564-04-01T00:00:00Z and “When was Shakespeare born?”, it returns 1 April 1564. I reran that exact current-source helper at 0e0e858238cb028b751a85a23f4690a0b0d48483; this is a component check, not a claim to have replayed the complete 10.0 Engine.
The earlier full-Engine 4.9-based run produced the same false precision. The source evidence for this row records April 1564 at month precision in the Julian calendar. Its RDF timestamp's day 1 is a serialization value, not evidence for an exact birthday. Conversely, actual January 1 birthdays must not all be reduced to year-only values. Timestamp digits alone cannot distinguish these cases.
Reproduce the formatter without importing stores:
import ast, pathlib, re
p = pathlib.Path('root/wander-train/reach_router_v1.py')
nodes = [n for n in ast.parse(p.read_text()).body
if (isinstance(n, ast.FunctionDef) and n.name == 'show_time')
or (isinstance(n, ast.Assign) and any(isinstance(t, ast.Name) and t.id == 'MONTHS' for t in n.targets))]
ns = {'re': re}
exec(compile(ast.Module(body=nodes, type_ignores=[]), str(p), 'exec'), ns)
print(ns['show_time']('1564-04-01T00:00:00Z', 'When was Shakespeare born?'))
A reviewed implementation and explicit source-bound metadata are published in the dated repair patch, with source evidence and scoped measurements. The patch also contains the separately reported astronomy repair; inspect its date-specific paths rather than treating the whole patch as an isolated formatter fix. It preserves precision/calendar/uncertainty and declines uncovered dates instead of inventing exact days. The sidecar covers a bounded 200 entity/property pairs, not the full world.
The later operations/premise patch consumes those date witnesses for work-year conditions and avoids treating absent source rows as proof of contradiction. It is linked as dependent follow-up work, not claimed to apply unchanged to 10.0's new operations code. These larger metadata/consumer changes are deliberately outside PR #2. Their retained 4.9-based tests are not a fresh 10.0 release qualification.
Following your update on #5: extending coverage beyond the 200-pair sidecar is useful, but I would keep the digit fallback explicitly separate from source-backed dates.
A non-first day does not establish that the source assertion had exact-day precision, a Gregorian calendar, no uncertainty qualifier, or a usable rank. Conversely, the first day of a month can be an actual exact date. The 1583 threshold does not recover the missing calendar metadata. This is an information-loss issue, rather than something a different cutoff can repair.
Our importer binds the exact legacy literal to a statement from matching JSON/RDF revisions and retains precision, calendar, rank and qualifiers. It can extend coverage incrementally without changing that contract. Where metadata is absent, an inspection operation can expose the raw stored literal with precision/calendar marked unknown; it should not supply a source-confirmed exact date or feed date ordering and publication-year premise checks as though that metadata were known.
Could the released fallback distinguish that raw-literal interpretation from a source-bound answer, and preserve the stricter boundary in comparison/year consumers? We haven't inspected the unpublished v37d implementation; this is feedback on the policy described in #5, not a claim about a new executed counterexample.