Capture Contract¶
Governing rule¶
Capture first. Preserve exactly. Interpret separately. Classify later. Present through composable views.
The capture contract accepts a raw Source Record and creates one stable Idea Card. It does not normalize, trim, rewrite, or repair the raw source.
Trigger grammar¶
The first-class tokens are IDE#, QUE#, and DEC#. A token is recognized case-insensitively only when the characters immediately before and after it are not ASCII letters or digits. Multiple distinct tokens may occur in one source. primary_trigger selects which present token determines the Card role; otherwise the first token is primary.
PRJ:name is routing metadata, not a capture boundary token.
Offset semantics¶
All stored offsets use unicode_code_point units. Offsets refer to the exact, unmodified Source Record. Adapters must convert platform-native offsets—such as UTF-8 bytes or JavaScript UTF-16 code units—before delivery.
Normalization may be used in a temporary parsing representation, but normalized text must never replace the Source Record or define its stored offsets.
Source identity and revisions¶
A bridged delivery supplies:
source_platform;source_conversation_id;source_message_id;- positive integer
source_revision; - stable delivery
idempotency_keywhen available.
The tuple of source identity, revision, and primary-trigger range identifies a capture. Re-delivery of the same tuple and exact source returns the existing Card. Reuse of that identity or idempotency key with different source text is rejected. An edited platform message must increment source_revision; it creates a new Card rather than rewriting the earlier Source Record.
Consent and origin¶
Manual capture is local user action. A delivery declaring delivery_mode: bridge must also provide complete source identity and consent_confirmed: true. This is contract scaffolding, not a completed platform integration or multi-user authorization system.
Interpretation boundary¶
Snapshots and Results append separately from the Source Record. AI-generated classifications, titles, and associations that are not accepted belong in proposal state. Proposed material is excluded from authoritative Card payloads and ordinary views until a future explicit acceptance capability is implemented.
Storage enforcement¶
The database prevents updates to Source Record columns and prevents Idea Card deletion. Status may develop—for example, a Question may become answered—without changing its source evidence.