lib

social-events.md (60272B)

---

 # Public Social Event Substrate
 
 Status: active implementation contract
 
 Scope: public Radroots social Nostr event models, codecs, and deterministic conformance vectors in
 this repository.
 
 ## Purpose
 
 The public social event substrate extends the Radroots event family beyond profile, farm,
 operational listings, and trade workflows while keeping relay runtime behavior, application
 projections, moderation services, and private Field business documents outside this repository's
 event-contract boundary.
 
 The target implementation is standards-first and Radroots-named. Event models live in
 `radroots_event`, canonical encode/decode behavior lives in `radroots_event_codec`, and
 deterministic fixtures live under `contracts/conformance`.
 
 Calendar behavior is based on
 [NIP-52](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/52.md)
 and its collection metadata uses
 [NIP-51](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/51.md),
 while text-note Reply threading follows
 [NIP-10](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/10.md),
 deletion requests follow
 [NIP-09](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/09.md),
 and kind-`1111` Comment threading follows
 [NIP-22](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/22.md),
 all at NIPs commit `bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91`. Calendar media uses the public
 Blossom primitives governed by the protocol pin in
 [`blossom-media.md`](blossom-media.md). The upstream NIP-52 rules and the stricter Radroots
 authoring and admission profile are separate contract layers.
 
 ## Implementation Inventory
 
 The repository implements strict authored and verified-projected kind `1` root-post profiles, a
 separate strict-authored and tolerant-inbound kind `1` NIP-10 Reply profile, a strict-authored and
 tolerant verified-inbound kind `1111` NIP-22 Comment profile, a strict-authored and tolerant
 verified-inbound kind `5` NIP-09 deletion-request profile with pure deterministic suppression
 evaluation, kind `7` `Reaction`, generic `List` entries, operational listing
 records through `OperationalListing`, the raw kind-`30402` profile partition and validated
 FoodAvailability authored, verified-admission, and revision contract, articles, generic public
 file metadata, calendar date events, calendar time events, reposts, generic reposts, calendar
 collections, RSVP events, and reports.
 
 The closeout contract requires:
 
 - complete model and codec coverage for the approved public social event families
 - kind and tag constants for the approved NIP surface
 - ordinary kind-1 compatibility reads plus strict Update, PhotoUpdate, and Ask authoring
 - strict marked direct and nested NIP-10 Reply authoring plus tolerant positional inbound admission
 - strict NIP-22 `AuthoredNip22Comment`,
   `RadrootsInboundNip22CommentProjection`, and
   `RadrootsAdmittedNip22CommentEvent` behavior without legacy `e_root` or
   `e_prev` authority
 - strict NIP-09 `AuthoredNip09DeletionRequest`,
   `RadrootsInboundNip09DeletionProjection`, and
   `RadrootsAdmittedNip09DeletionRequestEvent` request behavior plus a separate
   pure `RadrootsNip09SuppressionDecision` evaluator without storage authority
 - strict NIP-25 `Reaction` behavior where empty content is a valid like
 - explicit optional `published_at` support for NIP-99 classified-listing parity
 - NIP-65 relay-list validation evidence through `List`
 - conformance vectors and canonical-event witnesses for every new or upgraded social event family
 
 ## Approved Event Families
 
 The MVP public social substrate includes:
 
 - strict `AuthoredUpdate`, `AuthoredPhotoUpdate`, and
   `AuthoredAsk` publication types plus verified tolerant projection for
   ordinary NIP-01 kind `1` events
 - strict `AuthoredNip10Reply` direct and nested publication plus
   `RadrootsInboundNip10ReplyProjection` for marked and deprecated positional
   inbound NIP-10 replies
 - strict `AuthoredNip22Comment` publication plus
   `RadrootsInboundNip22CommentProjection` and
   `RadrootsAdmittedNip22CommentEvent` for kind-`1111` NIP-22 Comments rooted
   only in kind `30402`, `31922`, or `31923`
 - strict `AuthoredNip09DeletionRequest` publication plus
   `RadrootsInboundNip09DeletionProjection` and
   `RadrootsAdmittedNip09DeletionRequestEvent` for effect-free kind-`5` NIP-09
   event and address deletion requests, followed by pure deterministic
   suppression evaluation over verified targets and admitted requests
 - `Article` for NIP-23 kind `30023` long-form content
 - generic public `FileMetadata` for NIP-94 kind `1063`
 - strict authored `AuthoredCalendarDateEvent`, tolerant
   `ParsedNip52CalendarDateEvent`, and strict admitted
   `AdmittedCalendarDateEvent` models for NIP-52 kind `31922`
 - strict authored `AuthoredCalendarTimeEvent`, tolerant
   `ParsedNip52CalendarTimeEvent`, and strict admitted
   `AdmittedCalendarTimeEvent` models for NIP-52 kind `31923`
 
 The production-v1 public social substrate includes:
 
 - `Repost` for NIP-18 kind `6`
 - `GenericRepost` for NIP-18 kind `16`
 - strict authored `AuthoredCalendar`, tolerant
   `ParsedNip52Calendar`, and strict admitted `AdmittedCalendar`
   models for NIP-52 kind `31924`
 - strict authored `AuthoredCalendarEventRsvp`, tolerant
   `ParsedNip52CalendarEventRsvp`, and strict admitted
   `AdmittedCalendarEventRsvp` models for NIP-52 kind `31925`
 - `Report` for NIP-56 kind `1984`
 - operational-listing profile validation through `OperationalListing` at NIP-99
   classified-listing kind `30402`
 - strict FoodAvailability details, deterministic unsigned authoring, verified tolerant projection,
   NIP-01 admission, and strict revision validation for focused kind-`30402` inputs, with explicit
   exclusion of Operational Listing and marker-free generic NIP-99 candidates
 - relay-list kind `10002` validation through `List`
 
 ## Contract Decisions
 
 `Post` remains a compatibility read projection for ordinary kind `1`
 text notes and older optional social metadata. It is not an authored boundary.
 The public raw `imeta` encoder and its generic tag-builder implementation are
 removed so callers cannot turn mutable strings into purported strict media.
 
 ### Kind-1 Post Trust Layers
 
 Strict authored root posts are private-field typestates. Update and Ask content
 must be non-whitespace and every profile is bounded to 131072 UTF-8 bytes.
 PhotoUpdate and optional Ask media use between one and 64 NIP-92 `imeta` tags.
 Each image emits exactly `url`, `x`, `m`, `dim`, `size`, and `alt`, in that
 order, followed by ordered repeatable `fallback` fields. Primary URLs are
 unique and occur as exact substrings of content. MIME is parameter-free
 canonical lowercase and matches `^image/[a-z0-9][a-z0-9.+-]*$` exactly;
 dimensions are nonzero `u32` values; size is a nonzero `u64`; alt text is
 non-whitespace and at most 4092 UTF-8 bytes. Authored events emit at most 4096
 tag elements; every element is at most 4096 bytes and all tag elements together
 are at most 131072 bytes, including the Ask marker. The strict image state
 retains the exact validated
 `imeta` representation that the codec emits, so limit validation and encoding
 cannot diverge. Authored posts also fit within the 262144-byte compact signed
 event limit after exact JSON escaping, tag-array punctuation, and a worst-case
 20-digit NIP-01 timestamp are counted; decoded content and tag limits do not
 operate as independent escape hatches around that wire budget.
 
 Every authored primary image is a `AuthoredImage` backed by an approved,
 byte-verified Blossom descriptor. Every authored fallback is an approved
 Blossom hash-path URL with the same digest. This typestate proves local
 descriptor-to-byte agreement only. Successful BUD-02 upload completion remains
 a separate runtime precondition before signing.
 
 Ask is kind `1` and deterministically emits exactly
 `["t","radroots-ask"]`. PhotoUpdate is also kind `1`; kind `20` is outside
 this contract. Update emits neither the Ask marker nor `imeta`.
 
 Inbound projection accepts only a `RadrootsSignatureVerifiedEvent`. Any `e`
 tag, including an empty or malformed one, selects `ThreadExcluded` before Ask
 or media inspection. This is an exclusion-only candidate classification and
 does not claim that the event is a valid NIP-10 reply; strict NIP-10 parsing and
 promotion remain separately owned. `verify_and_admit_post_event` returns
 `RadrootsPostAdmissionOutcome`: only `Root(RadrootsAdmittedRootPostEvent)`
 exposes an exact product contract, while
 `ThreadExcluded(RadrootsThreadExcludedPostCandidate)` preserves the verified
 event and exclusion projection. For roots, exactly one two-element Ask marker
 after ASCII whitespace trim and ASCII case folding selects Ask. Multiple
 normalized markers fail projection, while a malformed marker shape is retained
 as an ordered diagnostic. Ask precedes PhotoUpdate even when attached media is
 malformed. PhotoUpdate requires one through 64 wholly qualifying `imeta`
 entries; a malformed or mixed set becomes Update with ordered diagnostics.
 Unknown fields and repeatable fallbacks preserve wire order, while duplicate
 known singletons disqualify media.
 
 Inbound HTTP(S) media references remain unverified structural strings. The
 projection performs no retrieval and makes no Blossom, byte, upload,
 reachability, image-decoding, or safety claim. The registry therefore keeps
 ordinary unsigned kind-1 identification on `radroots.social.post.v1`; exact
 Update, PhotoUpdate, and Ask contracts use `AdmissionOnly` and are returned only
 by the verified projection/admission boundary.
 
 The event-contract registry assigns an explicit authoring policy to every
 contract. Strict Profile, Update, PhotoUpdate, Ask, NIP-10 Reply, NIP-22
 Comment, NIP-09 Deletion Request, NIP-52 date Event, NIP-52 time Event, and
 FoodAvailability contracts are `TypedOnly`;
 `radroots.social.post.v1` is `ReadOnly`; ordinary generic-draft contracts
 remain `GenericDraft`.
 `GenericEventDraft::new` therefore rejects the strict Profile contract and
 every governed kind-1, kind-5, or kind-1111 contract with
 `contract_not_draft_authorable`. Serialized drafts record registry version `7`
 and are accepted only after deserialization revalidates the registry version,
 contract, kind, shape, policy, recomputed event id, and known fields. The
 authored-plan signing boundary repeats that validation, so stale version-`1`
 through version-`6` drafts must be rebuilt. Typed root posts, Replies,
 Comments, Deletion Requests, date/time Events, and FoodAvailability values
 enter Nostr signing only through opaque typed
 builders that expose timestamp selection and signing, but no raw tag/content
 mutation or public conversion to the upstream builder. Publication remains a
 transport concern operating on signed events. The opaque generic builder
 rejects kind `0`, every kind `1` event, kind `5`, and kind `1111` before a
 signer is consulted.
 
 ### NIP-10 Reply Trust Layers
 
 `AuthoredNip10Reply` is an opaque, bounded authoring state. Direct
 Replies contain one root reference; nested Replies contain one root and one
 distinct parent reference. Each reference carries a validated 64-character
 lowercase event id, a referenced-author pubkey, and an optional
 `NostrRelayHint`. The relay hint profile accepts only byte-stable ASCII
 WebSocket URLs: an exact lowercase `ws://` or `wss://` scheme; a canonical
 lowercase DNS, four-octet IPv4, or bracketed pure-hex RFC 5952 IPv6 authority;
 an optional canonical decimal port from `1` through `65535`; and an RFC 3986
 ASCII path-abempty and optional query whose percent escapes use uppercase
 `%HH`. DNS labels are 1 through 63 bytes, hosts are at most 253 bytes, and
 punycode (`xn--`) labels plus final all-decimal or `0x`-hex labels are rejected.
 The profile also rejects IDNA or percent-encoded hosts, legacy IPv4 forms,
 userinfo, fragments, controls, spaces, backslashes, and any
 normalization-dependent spelling.
 
 Relay syntax and Reply wire budgets are separate. The relay-hint type can hold
 a canonical URL whose path is longer than one tag element, while authored
 construction and verified inbound projection independently enforce the
 4,096-byte tag-element ceiling and return `reply_tag_element_too_large`.
 Content is non-whitespace and shares the root-post content, total-tag-byte, and
 compact signed-wire budgets.
 
 Strict authoring is deterministic. A direct Reply emits
 `["e",<root-id>,<relay-or-empty>,"root"]` followed by the root author's
 two-element `p` tag. A nested Reply emits the root `e` tag, then
 `["e",<parent-id>,<relay-or-empty>,"reply"]`, then the root and parent author
 `p` tags in that order; equal authors are emitted once. No other authored tag
 shape is accepted. Signing is exposed only through the sealed
 `Nip10ReplyBuilder`; publication remains transport-owned.
 
 Inbound projection requires a signature-and-id verified envelope. It accepts
 preferred marked `e` references, including the optional NIP-10 author hint, and
 supplemental unmarked `e` citations in the same event. An empty marker slot is
 treated as absent so a citation may retain its optional fifth-element author
 hint. Malformed supplemental references are ignored with ordered diagnostics
 without erasing an otherwise unambiguous marked Reply. The projection also
 accepts deprecated positional references where the first `e` tag is the root,
 the last is the parent, and intermediates are citations. Empty marker slots
 remain absent in this mode, including when a fifth-element author hint exists.
 Malformed intermediate citations become diagnostics; malformed root or parent
 anchors remain hard failures. Because NIP-10 makes
 participant propagation, relay hints, and referenced-author hints advisory,
 blank content or absent `p` tags do not erase an otherwise unambiguous inbound
 Reply. Malformed optional relay, author-hint, citation, and participant metadata is
 retained in the verified envelope and exposed as ordered typed diagnostics;
 valid relay hints are projected through the same `NostrRelayHint`
 profile used for authoring, and rejected hints remain verbatim in the ordered
 diagnostic's raw tag. This tolerant read-side behavior never weakens strict
 authored output.
 
 The registry's Reply `e` and `p` tag contracts describe normalized qualifying
 semantic references. They do not claim that every malformed optional raw tag
 retained by the verified envelope is itself a valid identifier-bearing tag.
 
 Any `e` tag excludes a kind-1 event from root-card admission before Ask or
 media classification. A thread-excluded candidate can be promoted only by the
 separate NIP-10 Reply admission boundary; a Reply carrying Ask or media
 metadata therefore remains a Reply and never becomes a root card. Admission
 proves only the Reply envelope's NIP-01 id and signature plus its NIP-10
 structure. It does not retrieve a referenced event or prove its existence,
 kind, signature, author, relay availability, or relationship to the declared
 author hint.
 
 The signer backend's externally supplied unsigned-event operation and the
 standard NIP-46 `sign_event` method are explicit low-level interoperability
 boundaries. Their signed results prove Nostr cryptographic authorization only;
 they do not confer a Radroots typed product-authoring claim and are not product
 authoring entry points. Relaying an already signed event is likewise a generic
 transport operation with no Radroots authoring claim.
 
 Each post and Reply operation owns exact valid and invalid case kinds in
 `contracts/operations.toml`. The canonical and packaged conformance suites
 execute every public Update, PhotoUpdate, and Ask authoring function, verified
 projection, admission function, and NIP-10 Reply authoring, projection, and
 admission boundary; they compare complete deterministic wire parts or
 projections and enforce stable negative error codes. Xtask validation pins the
 complete operation namespaces, ownership metadata, public types, and exact
 case-id-to-kind corpus; it rejects missing, duplicate, unclaimed,
 mis-prefixed, or substituted cases.
 
 ### NIP-22 Comment Trust Layers
 
 The strict Radroots [NIP-22](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/22.md)
 profile is kind `1111` and admits only event or address roots whose `K` kind is
 `30402`, `31922`, or `31923`. External `I`/`i` authority is unsupported, and
 kind `1` is deliberately excluded because text-note threads use the separate
 NIP-10 Reply boundary. Legacy `e_root` and `e_prev` tags have no authority in
 this contract.
 
 `AuthoredNip22Comment` is an opaque, non-Serde authoring state. Canonical
 tag order is `E,K,P,e,k,p` for a top-level event root,
 `A,K,P,a,e,k,p` for a top-level address root, and
 `E,K,P,e,k,p` or `A,K,P,e,k,p` for a nested event or address root,
 respectively. Authored `E` and parent or direct `e` event references always
 have four elements, retaining an empty relay slot when needed and ending with
 the asserted author hint. Authored `A`, `a`, `P`, and `p` tags have two
 elements plus an optional relay. The address-root revision `e` tag has two
 elements plus an optional relay and never an author hint. Top-level `k`
 repeats the supported root kind; nested `k` is exactly `1111`.
 
 Inbound projection accepts only a `RadrootsSignatureVerifiedEvent` and resolves
 the `E`/`A`, `K`, `P`, `e`/`a`, `k`, and selected `p` authority independently
 of tag order. Cardinality, shape, canonical numeric spelling, supported kind,
 coordinate kind and author, event author hints, and direct or nested
 relationships are hard validity rules. Supplemental unknown tags, `q` tags,
 and unselected valid lowercase `p` mentions remain available through the exact
 raw tags and projection. Inbound NIP-22 reference event IDs, public keys, and
 coordinate-author hex accept either ASCII hex case; typed projection normalizes
 those values to lowercase while exact raw tags retain the original spelling.
 Invalid advisory relay and participant metadata is reported through stable
 ordered diagnostics; a well-formed author hint that conflicts with required
 `P` or selected `p` authority is a hard error. This tolerance does not broaden
 the supported roots or authored forms.
 
 `RadrootsAdmittedNip22CommentEvent` keeps the projection bound to the envelope
 whose NIP-01 id and Schnorr signature were verified. Admission proves the
 Comment event and its strict profile only. It does not retrieve a root,
 revision, or parent or prove that the referenced event exists, carries the
 asserted kind, was signed by the asserted author, or is available at a relay.
 
 NIP-10 Reply and NIP-22 Comment references share
 `NostrRelayHint`. Relay syntax is independent of the Comment resource
 profile: content is limited to 131072 UTF-8 bytes, a Comment to 1024 tags, all
 tags to 4096 elements including tag names, each element to 4096 UTF-8 bytes,
 aggregate tag-element bytes to 131072, and the compact signed event to 262144
 bytes.
 
 The complete public operation namespace is exactly
 `social.comment.build_authored_draft`,
 `social.comment.project_verified_event`, and
 `social.comment.verify_and_admit_event`. Contract
 `radroots.social.comment.v1` is registry-v7 `TypedOnly` for authoring and
 `AdmissionOnly` for unsigned matching. Generic kind-`1111` signing and client
 publication are reserved before signer access.
 
 `contracts/conformance/vectors/comment/verified_profile.v1.json` is the
 canonical 114-case self-contained Comment corpus. Its authored inputs are
 explicit, and every projection or admission case carries its complete fixed
 signed event JSON rather than a mutation recipe, secret key, or generated base.
 The packaged mirror is byte-identical and exercises exact valid projections,
 diagnostics, resource boundaries, error precedence, and NIP-01 admission.
 
 ### NIP-09 Deletion Request Trust Layers
 
 The strict Radroots
 [NIP-09](https://github.com/nostr-protocol/nips/blob/bdfa7e62ef87fcfcb992b1a27aee49d36b0b4f91/09.md)
 profile is kind `5`. `AuthoredNip09DeletionRequest` is an opaque,
 non-Serde authoring state that requires at least one valid `e` event-id target
 or `a` NIP-01 replaceable/addressable coordinate. Each event target has a
 caller-asserted kind advisory in `0..=65535`. Replaceable coordinates of kind
 `0`, `3`, or `10000..=19999` require an empty identifier; addressable
 coordinates of kind `30000..=39999` preserve an opaque identifier.
 
 Authored construction normalizes and sorts event ids and coordinates, rejects
 duplicates after normalization, derives the complete unique ascending kind
 set, and emits two-element tags in exact `e`, `a`, then `k` groups. Event
 target kind values and inbound `k` tags remain advisory: the authoring and
 projection layers do not retrieve the referenced event or prove its kind.
 
 `project_verified_nip09_deletion_request_event` accepts only a
 `RadrootsSignatureVerifiedEvent`. It enforces kind `5` and the request resource
 budgets before target parsing. Unknown tags and trailing target elements remain
 in exact raw order. Valid targets are deduplicated by normalized identity,
 retain first-seen tag provenance, and are exposed in canonical sorted views.
 Malformed `e` or `a` targets are hard errors. Malformed, noncanonical, or
 duplicate `k` advisories produce ordered diagnostics. When a request contains
 only address targets, a valid advisory outside the target-coordinate kinds is
 also diagnosed; an event target makes that correspondence unprovable.
 
 `RadrootsAdmittedNip09DeletionRequestEvent` binds the projection to the exact
 envelope whose NIP-01 id and Schnorr signature were verified. Admission proves
 only a valid bounded deletion request. It does not look up a target, establish
 same-author authorization, calculate an address cutoff, replace or suppress an
 event, mutate a store, or decide whether another deletion request is immune.
 Those remain separate evaluator and storage responsibilities.
 
 `evaluate_nip09_suppression` is the pure evaluator boundary. It accepts one
 signature-verified candidate event and a set of admitted deletion requests,
 never mutates either input, reads no clock or store, and returns an explicit
 decision with canonically ordered evidence. A kind-`5` candidate is always
 immune. Every other candidate can be suppressed only by a request from the
 same author. An `e` target is time-independent: an exact event-id match
 qualifies even when the request predates the candidate. An `a` target must
 match the candidate's canonical replaceable or addressable coordinate and
 suppresses revisions whose `created_at` is less than or equal to the inclusive
 maximum cutoff among qualifying requests. A later replacement remains
 unsuppressed. Advisory `k` tags never participate in authorization or
 suppression. Request ordering and repeated qualifying inputs cannot change the
 decision.
 
 The complete public operation namespace is exactly
 `social.deletion_request.build_authored_draft`,
 `social.deletion_request.project_verified_event`,
 `social.deletion_request.verify_and_admit_event`, and
 `social.deletion_request.evaluate_suppression`. Contract
 `radroots.social.deletion_request.v1` is registry-v7 `TypedOnly` for authoring
 and `AdmissionOnly` for unsigned matching. Generic kind-`5` signing and client
 publication are reserved before signer access.
 
 Deletion-request content is limited to 131072 UTF-8 bytes, a request to 1024
 tags, all tags to 4096 elements including tag names, each element to 4096 UTF-8
 bytes, aggregate tag-element bytes to 131072, and the compact signed event to
 262144 bytes. The canonical 80-case self-contained corpus is
 `contracts/conformance/vectors/deletion/verified_profile.v1.json`. Authored
 inputs are explicit and every projection or admission input contains one
 complete compact fixed signed event JSON. The byte-identical packaged mirror
 contains no secret or private key, nsec, seed, generator, mutation, base, or
 boundary-expansion recipe, and expected projections expose no authorization,
 suppression, or store-mutation effect.
 
 Suppression behavior is governed separately by
 `contracts/conformance/vectors/deletion/suppression.v1.json` and its
 byte-identical packaged mirror. Its fixed inputs exercise direct event targets,
 inclusive address cutoffs, later replacements, requests that predate their
 targets, kind-`5` immunity, unrelated authors, mixed qualifying requests, and
 input-order independence. The evaluator produces evidence only; neither
 fixture nor operation authorizes a store mutation.
 
 ### NIP-09 Durable Reconciliation
 
 Event-store schema version `2` installs `0002_nip09` without changing the
 byte-pinned version-1 schema input. Its reconciliation-v1 hook re-verifies
 every durable raw envelope, rebuilds registry-v7 admission and
 addressable-feed-v1 raw heads, and persists normalized event-coordinate,
 deletion-request, event-target, and address-target facts under a fresh random
 32-byte source generation.
 
 The same generation partitions canonical addressable-head state and its
 append-only transition history. State records the raw head, admission result,
 visible or suppressed outcome, canonical NIP-09 evidence, and exact transition
 cause. Exact event targets are timestamp-independent; address targets retain
 the inclusive request-time cutoff; unauthorized requests remain evidence
 without suppressing another author's event; and kind-`5` requests remain
 immune. Raw envelopes and tags are never rewritten or removed to represent
 suppression.
 
 Initial reconciliation and repeated full rebuilds share one transactional
 marker-first protocol. The marker binds the exact prior generation, immutable
 raw counts and high-water sequence, and global transition floor. An impossible
 deferred foreign-key barrier makes every partial marker state uncommittable;
 the marker can close only after the rebuilt generation is internally complete.
 Successful rebuilds append a fresh generation and retain every historical
 generation, fact, state, and transition as immutable authority.
 
 Schema inspection, migration, rollback, and standalone status bind their
 catalog, ledger, history, and event-store reads explicitly to SQLite's `main`
 database. Before authority access or mutation, each relevant connection rejects
 temporary objects whose name or target table collides with declared
 event-store ownership, the migration ledger, or the reserved
 `radroots_event_store_` namespace using SQLite's ASCII-case-insensitive
 identifier semantics. Unrelated temporary and shared-schema state remains
 caller-owned. Full foreign-key reports may therefore retain unrelated
 shared-schema violations, while a violation whose child table is declared as
 event-store-owned or uses the reserved namespace fails with typed event-store
 integrity evidence.
 
 Projection cursors are bound to the active source generation. A projection
 version change, unbound legacy cursor, or source-generation change requires a
 typed rebuild ticket that captures the target generation and raw high-water
 sequence plus the exact prior cursor revision. Consuming that ticket after the
 rebuild commits the cursor at that captured high-water even if later raw events
 have arrived, then leaves those events for normal catch-up. It rejects
 concurrent cursor modification, replay, generation rotation, and same-value
 ABA replacement.
 
 The byte-pinned reconciliation manifest binds migration `0002`, registry-v7
 inventory, semantic input vectors, frozen v1/v7 source entrypoints, and the
 executable result vector at
 `contracts/conformance/vectors/event_store/nip09_reconciliation.v1.json`.
 It also binds the owned and borrowed transaction wrappers by production AST
 identity. The borrowed wrapper uses a nested savepoint, so a failed ingest
 cannot be ignored and then partially committed by its caller. Owned and
 borrowed ingest paths explicitly roll back a primary ingest failure and retain
 both failures if rollback also fails. The complete
 production AST identities of the versioned reconciliation core and shared
 raw-head storage modules are frozen independently of post-core product
 extensions. Post-core trade and transport-observation orchestration has no
 SQLx authority; it receives a private transaction capability whose fixed
 production methods may reach only literal SQL for the declared operation/table
 pairs, never protocol authority, cursors, migration history, attached
 databases, dynamic SQL, or schema mutation. The capability borrow ends before
 a final authenticated validator compares the core's source/generation
 authority, indexed raw and transition bounds, marker state, and main/temp
 schema versions and returns the receipt. Full cardinality and replay checks
 remain mandatory on explicit migration and rebuild integrity paths instead of
 running full scans for every ingest.
 The migration rejects unbounded local-cache reconciliation before any schema
 change and repeats the same capacity check under its serialized write
 transaction. Event and tag authority are then loaded in checked 512-row pages.
 Candidate heads consider only exact event- and address-target request indices;
 shared matches are merged once in canonical order without cloning request
 payloads.
 Schema inspection validates every applied hook in migration order rather than
 only the newest migration.
 This is local derived-state authority only. It does not assert relay deletion,
 network-wide disappearance, or authorization to mutate a remote store.
 The raw SQL pool is a fully trusted escape hatch rather than a security
 boundary; arbitrary DML or reproduction of the internal maintenance protocol
 is outside the supported mutation contract.
 
 ### Durable Visibility, Transition Feed, and Food Projection
 
 Event-store schema version `3` installs one central current-visibility authority,
 `radroots_event_store_current_visibility_v1`, for every persisted event. Ephemeral events never
 enter durable storage. Regular events are their own raw heads; replaceable and addressable events
 are compared with the current raw head for their coordinate. The authority composes that raw-head
 selection with registry-v7 admission and canonical NIP-09 evidence. All-event reads that claim
 current visibility, including `current_event_visibility_v1`, `event_visibility`, `visible_event`,
 and `visible_event_head`, must delegate to this view and fail closed on incoherent state. A current
 addressable product projection may instead join the transactionally maintained
 `radroots_event_store_addressable_head_state` materialization, but must bind the active generation,
 complete coordinate and head identity, admission, contract, visibility, and NIP-09 outcome. The
 FoodAvailability queries use that bounded specialization.
 
 The decision precedence is exact: a non-admitted event is `not_admitted`; otherwise an admitted
 event that is not the raw head is `not_current`; otherwise an admitted raw head with a suppressed
 NIP-09 outcome is `suppressed`; every remaining admitted raw head is `visible`. NIP-09 evidence is
 computed independently before the current-head decision, so an admitted `not_current` event can
 retain visible or suppressed historical evidence without becoming product-visible. Non-admitted
 events carry no NIP-09 evidence. Admitted events also retain the visible reasons for no authorized
 reference, an author mismatch, or an address cutoff that precedes the target. A persisted kind-`5`
 deletion request is immune, carries visible `deletion_request_immune` evidence with no request
 identifiers or cutoff, and cannot be suppressed by another kind-`5` request.
 
 Addressable transition feed version `1` accepts one through 64 input kinds, all in the
 `30000..=39999` range, and fingerprints their sorted, deduplicated canonical set. A cursor binds the
 active 32-byte source generation, feed version, exact scope fingerprint, and last scanned global
 transition sequence. With no cursor, scanning starts at the active generation floor. A cursor from
 another generation or scope is a mismatch, one below the floor is expired, one above the sealed
 high-water is ahead, and an absent sequence inside the sealed interval is corruption.
 
 Transition sequence is global rather than scope-local. A page therefore scans unrelated kinds and
 advances its cursor over them, checks sequence continuity, and reads at most 1024 transition rows.
 It returns at most the requested number of matching transitions, with a maximum request limit of
 64, and at most 4 MiB of visible raw-event JSON. If adding the next matching transition would cross
 either returned-item or aggregate-payload limit, the page stops before that transition and the next
 call retries it; a single matching row that alone exceeds the payload budget is a typed error. The
 page reports a fixed
 `source_high_water`, sets `has_more` from the last scanned sequence, and emits that sequence in its
 next cursor. It never advances past an unreturned matching transition.
 
 `RadrootsStoreProducedCanonicalEventV1` means the store selected a signature-verified, admitted,
 visible event at the instant represented by its containing transition. Historical transition pages
 can therefore carry a canonical payload whose event is `not_current` at the page's final
 high-water. The payload is replay input, not a detached proof of present visibility: consumers must
 apply every transition in sequence, including later retractions, and use the central current-
 visibility API when they need present-state authority. It does not mean that `raw_json` has a
 canonical JSON serialization. The wrapper exposes only the typed signed event id, author pubkey,
 created-at timestamp, kind, and verified opaque `raw_json`; it deliberately does not expose the
 backing `RadrootsStoredRawEvent` or duplicate its containing transition's generation/sequence
 witness. The remaining signed fields are available from `raw_json` through the verified event
 codec. Store `seq`, `inserted_at_ms`, `updated_at_ms`, source generation, and transition sequence
 are local database metadata and must not be persisted as cross-store event identity or replay
 authority. Consumers may transport `raw_json`, but must not infer cross-store equality from its JSON
 spelling instead of the signed event id.
 
 FoodAvailability projection version `1` has the sole scope kind `30402` and contract
 `radroots.food.availability.v1`. The post-core v2 capability applies pending global transitions in
 the same write transaction after protocol reconciliation. Its cursor advances over unrelated
 global transitions as well as matching ones. A visible admitted focused replacement is reverified
 and registry-v7 reprojected before insertion. A deletion, suppression, selected invalid event, or
 selected event outside the focused contract retracts the existing row for the author plus `d`
 coordinate. It never restores an older event; a later replacement created after an address-deletion
 cutoff can become visible and project normally. Projection rows are unique by generation, author,
 and `d`; image rows cascade with their parent, and projection insertion or deletion updates FTS5
 through database triggers in the same transaction.
 
 Point lookup uses author plus typed FoodAvailability identifier. Recent and search queries accept
 the `Any`, `Active`, or `Sold` status filter and a limit from 1 through 1000. Both return only the
 current visible projection and order by `published_at DESC, event_id ASC`. Search covers title,
 summary, content, and location. Its input is at most 256 UTF-8 bytes and 16 nonempty terms split on
 Unicode whitespace or control characters; terms are escaped as quoted FTS5 literals joined with
 `AND`, so caller input cannot introduce column selectors, operators, prefix matching, or grouping.
 Every returned projection row is bounded by the query limit and is individually checked against a
 fresh signature verification and registry-v7 reprojection of its immutable raw event, including its
 ordered image projection. Food point, recent, and search reads bind each row to the active
 generation's persisted addressable-head authority, including its exact head identity, admission,
 contract, and visible NIP-09 outcome. That state is maintained by the same transactional
 current-visibility predicate; bounded Food reads do not recompute deletion-reference history for
 every result row.
 
 For `RadrootsStoredFoodAvailabilityImageV1`, `qualifies()` means only that tolerant inbound image
 projection produced no structural diagnostics. An ordinary valid HTTP(S) URL with valid dimensions
 can therefore qualify while `blossom_sha256()` is `None`. A digest extracted from a Blossom-shaped
 URL is structural metadata, not evidence that bytes hash to it or that upload, retrieval, decoding,
 safety, or availability succeeded. Strict product authoring still requires an approved
 byte-verified descriptor, and publication still requires runtime BUD-02 upload-completion evidence.
 Blossom-specific client behavior must require the typed digest and the applicable runtime evidence,
 not `qualifies()` alone.
 
 The FoodAvailability cursor seals active source generation, feed version, projection version, exact
 scope fingerprint, hook-manifest SHA-256, last transition sequence, and a nonnegative projected-row
 count. The addressable feed seal binds the same generation's floor, high-water, and contiguous
 count. Each supported projection page compare-and-swaps the prior sequence and row count; it can
 advance by at most 1024 global transitions and change the row count by at most 64 and no more than
 the number of scoped transitions in that interval.
 
 Ordinary schema inspection and FoodAvailability point, recent, and search reads use one bounded
 fast authority check. It verifies the active generation, feed floor/high-water/count seal,
 feed/projection/scope/manifest identity, cursor equality with the source high-water, and the
 nonnegative sealed row count without scanning all projection or FTS rows. Explicit migration,
 supported rebuild, and conformance integrity paths must call
 `audit_food_availability_projection_v1`: the exhaustive audit reverifies and reprojects every
 projected signed event, compares all columns and ordered images, binds each row to the active
 generation's latest applicable transition for its exact Food coordinate and visible event, requires
 the exact admitted and visible head-coordinate witness set and sealed projection and FTS counts, compares
 each FTS shadow row, and runs SQLite's FTS5 integrity check. The governed Food read view joins
 immutable raw JSON and aggregates ordered image rows so a bounded point/recent/search result does
 not issue per-row SQL lookups before those cryptographic checks.
 
 The fast seal detects drift across supported typed transactions; it is not a claim to detect
 arbitrary direct SQL, disk modification, or FTS index corruption on every hot-path read. `pool()` is
 a trusted escape hatch outside the supported mutation guarantees. A caller that uses it assumes
 authority for any resulting state; only a governed migration, rebuild, or conformance path that
 invokes the exhaustive validator can re-establish integrity evidence for that state.
 
 `Reaction` uses strict NIP-25 semantics. Empty content, `+`, `-`, emoji, and custom reaction
 content are valid when the target tags are valid. Missing targets remain invalid.
 
 `Report` intentionally tightens NIP-56 for the Radroots type: a reported pubkey `p` tag is
 required for a valid report, including event and file or blob reports.
 
 Generic public `FileMetadata` remains separate from private `FarmFileMetadata` even
 though both use kind `1063`. The public generic model must cover the current simple NIP-94 tags,
 including URL, MIME type, SHA-256 hash, original hash, size, dimensions, blurhash, thumbnail, image,
 summary, alt text, fallback, `magnet`, `i`, and `service`.
 
 ### FoodAvailability Domain Boundary
 
 Kind `30402` routing first inspects only the raw first element of each tag. The focused marker set is
 exactly `radroots:price_unit` and `radroots:quantity`; the Operational Listing marker set is exactly
 `radroots:primary_bin`, `radroots:bin`, and `radroots:price`. Focused-only, operational-only,
 marker-free generic NIP-99, and mixed-marker inputs are distinct partition results. This happens
 before profile tag-shape validation, so a malformed one-element marker still counts. Matching is
 exact and case-sensitive. `ClassifiedListingPartition` names those results
 `FocusedFoodAvailability`, `OperationalListing`, `GenericNip99`, and `Ambiguous`. The partition is
 allocation-free, does not inspect the event kind, marker values, or tag arity, and does not establish
 that either profile is valid.
 
 `FoodAvailabilityDetails` and its focused domain values are checked before construction.
 The identifier is 1 through 512 UTF-8 bytes, contains no whitespace, and contains no Unicode
 control or format character. Content must contain at least one scalar outside Unicode whitespace
 and the information-separator range U+001C through U+001F, and is bounded to
 131072 UTF-8 bytes; it is not normalized or subjected to the stricter metadata-text policy. Title,
 summary, and location are trimmed, nonempty, control-free text bounded to 4096 UTF-8 bytes.
 `published_at` is a canonical nonzero `u64` decimal and can be checked as no later than a supplied
 `created_at`.
 
 Price and optional quantity are canonical unsigned plain decimals with at most 28 ASCII digits
 excluding the optional decimal point. Price may be zero; quantity must be positive. Currency is
 exactly three uppercase ASCII letters. The dedicated unit vocabulary is `g`, `kg`, `lb`, `oz`,
 `each`, `dozen`, `bunch`, `punnet`, `bag`, and `basket`, and quantity uses the same unit as price.
 Status is exactly `active` or `sold`.
 
 Image dimensions are two nonzero canonical `u32` decimal components in `WIDTHxHEIGHT` form.
 Validated details accept no more than 64 images, reject duplicate URLs or Blossom digests, and
 accept only `AuthoredImage` values backed by an approved, byte-verified image descriptor.
 That proof establishes local descriptor-to-byte agreement only. It does not establish BUD-02 upload
 completion, decoded raster dimensions, content safety, retrieval, reachability, or network
 availability.
 
 The details model deliberately has no farm, bin, route, pickup, delivery, order, checkout, or other
 commerce-workflow field. `authored_food_availability_to_wire_parts` accepts these details plus
 `created_at`, requires `published_at <= created_at`, and emits unsigned kind-`30402` wire parts. Its
 closed tag sequence is exactly `d`, `title`, `summary`, `published_at`, `location`, `price`,
 `radroots:price_unit`, optional `radroots:quantity`, `status`, then zero or more `image` tags. Price
 is exactly amount plus currency, quantity is exactly amount plus unit, and image is exactly URL plus
 dimensions. The decoded tag budgets and the 262144-byte compact signed-event budget are both
 enforced. The operation neither chooses `created_at` nor signs or transports the result.
 
 Inbound projection accepts only a `RadrootsSignatureVerifiedEvent`. Raw marker partitioning occurs
 before focused tag validation: Operational Listing and marker-free generic NIP-99 candidates are
 explicit exclusions, while mixed markers are an error. A focused candidate requires the complete
 core profile and rejects tags that purport to add buyer, checkout, delivery, exception, group,
 invite, order, payment, pickup, proof, provenance, receipt, route, `route_stop`, or task capability.
 Other optional NIP-99 tags remain outside the focused projection and are ignored. Accepted inbound
 decimal values are normalized without exceeding the 28-digit wire bound, and three-letter currency
 is normalized to uppercase.
 
 Inbound image observations are not authored media typestates. The projection retains at most the
 first 64 tags in wire order and records stable ordered diagnostics for count overflow, malformed
 shape, invalid HTTP(S) URL, missing or invalid dimensions, duplicate URL, and duplicate Blossom
 digest. Image diagnostics do not invalidate an otherwise complete focused core. They confer no
 Blossom approval, byte agreement, upload, decoding, retrieval, safety, or availability claim.
 
 `verify_and_admit_food_availability_event` performs NIP-01 id and Schnorr verification before that
 projection and returns either `RadrootsAdmittedFoodAvailabilityEvent` or an explicit verified
 non-focused exclusion. The admitted type binds the projection to the verified envelope and exposes
 the admission-only `radroots.food.availability.v1` registry contract. The contract is `TypedOnly`:
 strict authored details are its only product-authoring input, and unsigned kind or tag matching does
 not confer focused admission.
 
 Revision validation accepts two independently signature-verified events and re-applies the exact
 authored wire profile to each side; tolerant normalized or diagnostic-bearing projections cannot
 enter this comparison. Kind, author, `d`, and `published_at` must remain stable. The candidate must
 have a later `created_at`, or the lower event id when both timestamps are equal. Invalid previous
 and current inputs have side-specific errors.
 
 With the `events` feature, `build_food_availability_event` fixes `created_at` during
 typed construction, derives the exact strict wire parts, and returns a sealed builder with no raw
 tag, content, or timestamp mutation. With the `signing` feature, the builder supports local signing.
 Generic builder signing rejects focused and mixed-marker kind-`30402` events before signer access.
 Marker-free generic NIP-99 and operational-only builders remain available for explicit
 compatibility. Relay publication remains transport-only and establishes no Radroots authoring
 claim.
 
 Behind the explicit non-default `legacy-ingest` feature, legacy replica ingestion verifies
 kind-`30402` identifiers and signatures before acquiring its write transaction, then selects the
 raw addressable head before profile decoding. Only the
 Operational Listing partition can reach the legacy trade-product projection. A signature-valid,
 coordinate-valid, selected focused event or marker-free generic NIP-99 event advances the raw head
 as excluded; selected invalid focused, mixed-marker, and malformed operational profiles advance it
 as rejected. Every selected excluded or rejected replacement removes an older operational
 projection, so stale events cannot resurrect it. A signature failure changes neither the raw head
 nor the projection; a missing or invalid `d` tag fails before an addressable head can be selected.
 The feature-gated public head-only helper rejects kind `30402`, which must use profile-aware legacy
 ingestion so head and projection changes remain atomic. Neither helper is a Phase 1 product ingest
 boundary.
 
 The typed Nostr boundary does not prove BUD-02 upload completion. Every media-bearing caller must
 obtain successful Blossom upload evidence before signing or publishing; byte-verified descriptors
 alone prove only local descriptor-to-byte agreement. Typed outbox persistence and upload-evidence
 bridging remain separate runtime responsibilities.
 
 ### Calendar Trust Layers
 
 Kinds `31922`, `31923`, `31924`, and `31925` have three explicit,
 non-interchangeable layers:
 
 | Layer | Public role | What success establishes |
 | --- | --- | --- |
 | bounded structural wire or envelope | preserves the complete NIP-01 event while validating wire shape, identifier syntax, and resource limits | structural data only; it does not establish a matching event id or valid Schnorr signature unless the caller invokes the separate verification operations |
 | tolerant NIP-52 parse | one of the `RadrootsParsedNip52*` date event, time event, calendar collection, or RSVP types | the expected kind and the pinned baseline NIP-52 semantics parse successfully; observed standard fields and tolerated wire spellings remain distinguishable from canonical authored data |
 | strict Radroots admission | one of the corresponding `RadrootsAdmitted*` calendar types | the parsed value also satisfies the canonical Radroots identifier, reference, metadata, media, date, or UTC-day profile applicable to that kind |
 
 The calendar `*_parsed_from_event` helpers construct a structurally checked raw envelope alongside
 the tolerant projection. Their names do not mean that the event id or signature has been verified.
 Before a caller treats relay data as accepted, it must recompute and compare the NIP-01 event id,
 verify the Schnorr signature against the event author, dispatch the event to the matching kind
 `31922`, `31923`, `31924`, or `31925` parser, and then apply strict admission when the Radroots
 profile is required.
 The kind-specific parsers reject the wrong kind, but neither baseline parsing nor strict admission
 performs cryptographic verification. An admitted model is therefore valid only while it remains
 bound to the already id- and signature-verified envelope from which it was parsed.
 
 Strict authoring is the outbound counterpart, not a fourth inbound verification state.
 `AuthoredCalendarDateEvent`, `AuthoredCalendarTimeEvent`,
 `AuthoredCalendar`, and `AuthoredCalendarEventRsvp` have private checked fields and
 encode deterministic `Nip01EventWireParts`. Wire parts contain only `kind`, `content`, and
 `tags`; the owning runtime still supplies `created_at` and author identity, computes the event id,
 signs the event, and publishes it.
 
 ### Baseline NIP-52 Parse
 
 Kinds `31922` and `31923` use plain-text description content. Empty content projects to no typed
 description. The `d`, `title`, and `start` tags are required singletons, and `end` is an optional
 singleton with an exclusive boundary. The tolerant common projection covers the pinned standard
 fields:
 
 - optional `summary`, `image`, and `g`
 - repeated `location` values without collapsing them to one value
 - repeated participant `p` tags containing a 32-byte hexadecimal public key, optional recommended
   relay URL, and optional role
 - repeated category `t` tags and absolute-URI reference `r` tags
 - repeated calendar-inclusion request `a` tags whose coordinates identify kind `31924`, with an
   optional recommended relay URL
 - the deprecated singleton `name` as observed compatibility data; it never replaces the required
   `title`
 
 Other tags remain available only through the complete structural envelope. Baseline parsing does
 not silently promote unknown fields into the typed calendar contract.
 
 Kind `31922` uses semantic Gregorian `YYYY-MM-DD` values for inclusive `start` and optional
 exclusive `end`. Year zero, impossible dates, non-canonical date spellings, and an `end` that is not
 later than `start` are invalid. When `end` is absent, the event ends on the same date as `start`.
 Uppercase `D` is not defined for date-based events by the pinned NIP-52. The tolerant parser retains
 every observed uppercase-`D` tag as uninterpreted extension data so standards-compatible inspection
 remains lossless at that boundary; strict Radroots admission rejects any such date-event extension.
 
 Kind `31923` uses unsigned decimal Unix seconds for inclusive `start` and optional exclusive `end`.
 When `end` is absent, the event is instantaneous. At least one uppercase-`D` day index on which the
 event takes place is required, and the tolerant parser rejects indices outside the event interval.
 In line with NIP-52's `SHOULD` for multiple coverage tags, baseline parsing does not require either
 the start-day index or complete coverage. It also preserves duplicate, unordered, or leading-zero
 numeric `D` observations for
 diagnostics; those spellings are parser tolerance, not canonical authored output. Baseline parsing
 does not apply the Radroots 366-day admission limit. Optional `start_tzid` and `end_tzid` values must
 be exact identifiers in the bundled IANA Time Zone Database (`jiff-tzdb` `0.1.8`, TZDB `2026c`).
 When `end_tzid` is absent and `start_tzid` is present, the effective end time zone is `start_tzid`.
 
 An inbound baseline `image` is only a structurally valid absolute URI. It is not a Blossom claim,
 an approved reference, or evidence about bytes or network state.
 
 Kind `31924` is a calendar collection, not a generic list or list-set publication surface. Its bounded
 plain-text `content` is the NIP-52 detailed description and is required on wire even when empty.
 The required singleton `d` and `title` tags identify and name the collection. Repeated `a` tags
 contain only kind-`31922` or kind-`31923` addressable coordinates and may each carry their own
 recommended relay URL. A collection with no `a` tags is valid. The optional singleton
 `description` and `image` tags are NIP-51 list metadata; `description` is distinct from NIP-52
 description content and the parser does not merge one into the other. The baseline parser accepts a
 structurally valid absolute `image` URI without making a Blossom or network claim. Singleton text
 tags have exactly two elements; collection `a` tags have exactly two elements plus an optional relay
 element.
 
 Kind `31925` is an RSVP with bounded optional free-form note content. It has exactly one required
 `d` identifier, one required `a` coordinate for a kind-`31922` or kind-`31923` event, and one
 required `status` value: `accepted`, `declined`, or `tentative`. Optional singleton `e`, `fb`, and
 `p` tags respectively identify one exact event revision, the `free` or `busy` availability state,
 and the event author. The `a`, `e`, and `p` references each carry an independent optional
 recommended relay URL; a relay hint on one reference is never copied to another. The `p` form is
 an author hint without participant-role semantics. The `d`, `status`, and `fb` tags have exactly
 two elements; the `a`, `e`, and `p` tags have exactly two elements plus an optional relay element.
 Baseline parsing preserves `fb` observed on a declined RSVP for diagnostics but treats its effective
 value as absent, as required by NIP-52. Parsing a syntactically valid `e` tag does not establish
 that it is a revision of the referenced addressable event.
 
 ### Strict Radroots Calendar Profile
 
 Strict authored and admitted calendar metadata uses canonical nonempty text, canonical participant
 values, validated lowercase-scheme `ws`/`wss` relay URLs, and lowercase geohashes. Relay URL host,
 port, path, and query spellings are preserved rather than normalized. The authored common surface supports repeated locations,
 optional geohash and summary, repeated participants, categories, absolute-URI references, and
 kind-`31924` calendar-inclusion requests. It intentionally does not author deprecated `name` tags.
 
 Strict kind-`31922` events never emit or admit uppercase `D`. Strict kind-`31923` events require
 canonical decimal timestamps and the exact, ascending, duplicate-free sequence of every UTC-day
 index covered by the interval, where `D = floor(unix_seconds / 86400)` and `end` is exclusive.
 Authoring derives this sequence rather than accepting it from callers. Strict authored and admitted
 time events cover at most 366 UTC days.
 
 Registry-v7 marks both Event contracts `TypedOnly`. Their authored models
 convert through the same immutable authored-plan boundary as every other
 strict product profile, and sealed Nostr builders allow local or opaque-host
 signing without exposing kind or tag mutation. Historical plan decoding
 re-runs tolerant parsing, strict admission, and exact authored tag-order
 validation; deprecated `name`, reordered tags, incomplete day coverage, and
 other inbound-tolerated spellings cannot become strict outbound plans.
 
 Strict kind-`31924` and kind-`31925` identifiers are syntax-valid 128-bit values encoded as exactly
 22 unpadded base64url characters. This shape does not prove uniqueness; an authoring runtime must
 generate a fresh identifier for every collection or RSVP identity. Strict collection authoring and
 admission require canonical title and optional NIP-51 description text, validated relay hints, and
 duplicate-free event coordinates while still permitting an empty collection. Collection event
 references remain limited to kinds `31922` and `31923`.
 
 Strict RSVP authoring and admission require canonical `a`, optional `e`, and optional `p`
 references. An admitted `p` author hint must match the public key in the `a` coordinate. Authored
 RSVPs never emit `fb` when status is `declined`; inbound baseline and admitted values retain such an
 observation only for diagnostics and return no effective free/busy state. Neither baseline parsing
 nor strict admission proves that a referenced revision exists, that it matches the addressable
 event, or that the RSVP author is authorized to answer for another party.
 
 Calendar images have an explicit progression of trust. Tolerant inbound parsing accepts any
 absolute image URI. Strict inbound admission requires a structural Blossom hash-path URL, but does
 not prove approved-reference policy, byte agreement, upload completion, reachability, or image
 safety. Strict authored models accept only `AuthoredImage`, which wraps an approved,
 byte-verified Blossom descriptor declared as `image/*`. That typestate proves local
 descriptor-to-byte agreement only.
 
 A publication runtime must not sign or publish a media-bearing calendar draft until the exact blob
 has completed a successful BUD-02 upload and the runtime's bounded retrievability check has
 succeeded. Consumers remain responsible for bounded retrieval, redirects, content decoding, and
 format-safety policy. No calendar model upgrades an observed relay URL into either an upload receipt
 or an availability guarantee.
 
 Product routing uses surface-specific kind classifiers rather than a broad public-social set. Home,
 Events, Market, Map, and Profile public-content candidates are explicit. A kind-`30402` value alone
 does not select FoodAvailability: raw marker partitioning first distinguishes focused,
 operational, generic NIP-99, and ambiguous candidates, and only signature-verified focused admission
 returns the FoodAvailability contract. Report kind `1984` is a moderation/admin candidate, not
 normal feed content. Relay and HTTP auth kinds are transient and excluded from durable social and
 farm-ops candidate sets. Private farm operations candidates include the farm workspace manifest,
 farm CRDT change envelope, farm file metadata, and the supported NIP-29 group event subset.
 
 `RadrootsRelayList` is not a separate model type in the target contract. Operational listing records
 are represented through `OperationalListing`, and NIP-51 standard and list-set entries,
 including NIP-65 relay metadata kind `10002`, are represented through `List`. NIP-51
 taxonomy may classify kind `31924` as a calendar list, but generic list and list-set decoding or
 authoring must reject that kind; only the calendar-specific model and codec may parse or publish it.
 
 ## Exclusions
 
 This substrate does not include `RadrootsFeedItem`, `RadrootsMapPin`, NIP-72 community events,
 checkout or payment events, or public task, harvest, work-session, approval, or other Field business
 document event types.
 
 Task records, work sessions, harvest records, approvals, and similar Field business objects remain
 CRDT document semantics carried inside the CRDT change envelope unless a later contract explicitly
 promotes them.
 
 ## Consumer Boundary
 
 The public social surface is event and codec substrate first. Consumer packages may wrap these
 models and codecs, but this repository owns only the core Rust contracts and deterministic
 conformance evidence. Package-specific operation maps, bindings, and generated artifacts are outside
 this contract boundary.
 
 ## Conformance Boundary
 
 Every new social codec and every upgraded existing social codec must have deterministic valid and
 invalid conformance vectors before closeout. The FoodAvailability profile vector assigns exact
 valid and invalid case kinds to strict authoring, verified projection, combined verification and
 admission, and revision validation. The canonical NIP-22 Comment vector assigns all 114 exact
 case ids and kinds to its three governed operations and has a byte-identical packaged fixture.
 Other upgraded vectors must include reaction, operational-listing, farm, list, and list-set
 behavior whose public contract changes during the refactor.
 
 Social vectors are repo-owned and synthetic. They must not depend on application relay state, local
 databases, external services, root fixture catalogs, or ambient machine state.