#POC-1 — Foundation: data model, pipeline, input

[nsunku]

Summary

• The skeleton every other ticket plugs into. Defines the data shapes, the linear pipeline that threads them together with stubbed stages, and the one minimal way to feed input in.
• Freeze the contracts by mid-week so Pair B can build POC-2 against them.

Reuse note:

• GL-1 (already in flight) has a CanonicalMessage dataclass and a LogEvent shape — adapt the message/envelope structure here as a starting point. Do not pull in GL-1's log buffer, LogEvent.emit(), session-scoped buffering, or the encryption-layer hook. The POC has no logging framework, no session object, and no PII envelope; take the data shape, leave the production scaffolding.

What to build
Data models (typed, documented):

• Submission — case fields, narrative (free text, first-class field), certificate image (bytes or path)
• DocumentSignal, AuthenticitySignal, ConsistencySignal — the three detector outputs
• ReliabilityResult — score (1–100), band enum, sub_scores dict, weights dict, flags list, justification string, extracted_fields dict (the certificate data POC-2 reads, surfaced to the customer)

run_pipeline(submission) -> ReliabilityResult calling stubbed stage functions in order: intake → document analysis → authenticity → consistency → scorer → result

Minimal intake: a FastAPI POST /score accepting image + narrative + case fields, OR a python -m poc.cli score equivalent — returns ReliabilityResult as JSON

No channels, no auth, no storage

Acceptance criteria

• All models typed, documented, and frozen by mid-week
• narrative is an explicit first-class field on Submission
• run_pipeline() runs end-to-end on stubs and returns a valid ReliabilityResult
• band enum covers high, medium, low, escalate
• Endpoint or CLI accepts image + narrative + fields and returns JSON
• Unit test asserts the skeleton produces a well-formed result