
Document	System Architecture
Supersedes	`jalibor-architecture-v2.md` (v2.0, Aug 2026)
Status	Current — reflects production as of 21 Aug 2026
Companion	`pmc-specification-v0.3.md` (protocol specification)
Relationship	Jalibor is the reference implementation of Presence Mesh Consensus. This document describes implementation choices, which are not protocol requirements.
Audience	Engineers · technical diligence · protocol researchers

Reading note. This document describes the system as built. Where a mechanism is deployed and running it is marked current. Where it is a committed near-term design not yet in production it is design. Where it is a proposed direction that has not been settled it is [PROPOSED]. Nothing marked design or [PROPOSED] should be read as existing behaviour.

On numbers. This document contains no performance measurements, adoption figures, or benchmark claims. Every quantity stated is either a protocol parameter (a value the system is configured with) or a cost input (a third-party price). Absence of a measurement is represented as absence, never as an estimate.

Changelog — v2.0 → v2.1

Area	Change
Protocol name	The protocol formerly specified as Jalibor Consensus Protocol (JCP) is renamed Presence Mesh Consensus (PMC). There is now one protocol name, not two. Rationale in `pmc-specification-v0.3.md` §1.4.
Positioning	Jalibor restated as the reference implementation of PMC rather than its owner. Consequence: nothing in this document may be read as a conformance requirement — those live in the specification, §13.2.
Glossary	`JCP` entry removed; `PMC` entry restated as the protocol itself.

No architectural, schema, or deployed behaviour changed in v2.1. It is a naming and framing revision.

Changelog — v1.0 → v2.0

Area	Change
Presence verification	Documented as the normative core, server-side only. The deployed piecewise presence cone is now specified alongside the continuous analytic model, and the divergence between the two is stated openly (§6.4).
Identity	SMS OTP moved from feature-flagged to live in production. The `SMS_VERIFICATION` flag no longer exists. Consequences documented (§4.3).
Anti-sybil	Reframed: the barrier is identity, not position. Rationale and cost model added (§8).
Validation window	3-hour window added as a system-wide invariant across all three ingestion channels (§9).
Biometrics	WebAuthn documented as device lock, not authentication (§4.5).
Channels	Telegram single-use linking tokens (15-min TTL) documented (§9.3).
Privacy	Multimedia cut from MVP; camera permission removed, microphone retained. LATAM regulatory posture expanded (§13).
Surfaces	Four distinct surfaces documented; brand v3 migration noted as complete (§12).
Open items	Bug registry and limitation register formalised (§14).

1. Purpose and scope

Jalibor is Real-World Consensus Infrastructure: a system that establishes trusted, evolving consensus about physical-world events in real time, from independent observations made by nodes that were physically present.

It is not a security application. Security is the first application because the pain is acute and citizen validation is natural there, but the architecture makes no assumption specific to it. Everything in this document generalises to logistics, municipal operations, infrastructure monitoring, and any domain where the question is what is actually happening, right now, at this coordinate.

This document covers the system: surfaces, storage, identity, ingestion, verification, and the trust boundary. The protocol — the abstract rules by which observations become consensus, independent of this implementation — is specified separately in pmc-specification-v0.3.md.

1.1 The problem statement

Every existing system that records physical-world events is built for records: a database row, a police report, an isolated camera, a social media post. A record is a photograph of a moment that has already passed. It is authored by one party, it does not update itself, and nothing about it can be independently verified after the fact.

The physical world is not a record. It moves. And the question that actually matters operationally — is this happening now, and how sure are we — has no system that answers it.

1.2 What "consensus" means here

Not blockchain consensus. Blockchain consensus answers which totally-ordered history of writes does the network agree on, over data the network itself generated and can therefore re-validate. Jalibor's data is exogenous and not self-validating: it comes from the physical world, there is no oracle, no replay, and no fixed validator set.

The output is therefore not a commit. It is probabilistic confidence that decays — a live estimate of how sure the network is that something is happening, which weakens on its own unless independent presence keeps corroborating it.

2. Positioning constraints that bind the architecture

These are not marketing decisions. Each one has a structural consequence downstream.

Constraint	Architectural consequence
Infrastructure, never a security app	No domain-specific logic in the consensus path. Event categories are data, not code.
Events, not people	No identity is attached to an event record. Observers are pseudonymous node IDs.
Rejection does not exist	No negative-vote path exists anywhere in the schema or the API. Absence of corroboration is decay.
AI is an observer, never an oracle	AI nodes use the identical ingestion interface. No privileged write path exists for them.
No fabricated data, ever	Null is a legitimate value. No defaults are supplied to make a display look complete.
Derived values are derived	Confidence and contribution score are computed from source rows, never incremented.

2.1 Terminology canon

Observation · Validate · Confidence level · Reputation / Contribution score · Participant / Observer · Your area / Network.

Not used anywhere in code, copy, or schema: report/denuncia, confirm, trust, level/XP, neighbor/vecino, neighborhood/barrio.

3. System overview

                 ┌──────────────────────────────────────────┐
   SURFACES      │  landing/     app/      web/    enterprise/│
                 │  (marketing) (PWA)    (Web3)   (B2B site)  │
                 └───────────┬──────────────────────────────┘
                             │ HTTPS
                             │
   INGESTION     ┌───────────┴──────────┬──────────────┬─────────────┐
                 │   PWA client         │  WhatsApp    │  Telegram   │
                 │                      │  (Twilio)    │  (Bot API)  │
                 └───────────┬──────────┴──────┬───────┴──────┬──────┘
                             │                 │              │
                             ▼                 ▼              ▼
   ═══════════════════ TRUST BOUNDARY ═══════════════════════════════
                             │
   VERIFICATION  ┌───────────┴────────────────────────────────────┐
                 │  Edge Functions        PostgreSQL RPC          │
                 │  · validate-event      · presence weighting    │
                 │  · send-otp            · confidence recompute  │
                 │  · verify-otp          · anchor comparison     │
                 └───────────┬────────────────────────────────────┘
                             │
   STATE         ┌───────────┴────────────────────────────────────┐
                 │  PostgreSQL + Row Level Security               │
                 │  events · observations · nodes · subscriptions │
                 └────────────────────────────────────────────────┘

The single most important line in this diagram is the trust boundary. Everything above it is untrusted input, including input that arrived from our own PWA. Everything below it is where presence is verified.

3.1 Stack current

Layer	Technology	Note
Clients	Vanilla HTML / CSS / JS, single file per surface	No framework, no build step. Deliberate: each surface is auditable end to end in one file.
Hosting	GitHub Pages	Static. `github.com/Ernih/JBL` → `ernih.github.io/JBL/`
Backend	Supabase (project `sviddozldhdiockuxadj`)	Anonymous Auth, RLS, Edge Functions, PostgreSQL RPC
Maps	Leaflet.js	Event map in the PWA
Visualisation	Three.js	PMC live simulation and Presence Cone on the enterprise site
Voice/SMS	Twilio	WhatsApp channel and SMS OTP
Chat	Telegram Bot API	Telegram channel

4. Identity and authentication

4.1 The two-tier model

Jalibor separates device identity from verified participation. They are different problems with different threat models.

Tier	Mechanism	Answers
Device identity	Supabase Anonymous Auth	"Is this the same client that wrote the previous row?"
Verified participation	SMS OTP	"Is there a real, cost-bearing human behind this node?"

4.2 Anonymous Auth and owner-based RLS current

The system previously exposed an open anon key with permissive policies. It now issues a cryptographic identity per device through Anonymous Auth, and Row Level Security is owner-based: a row can only be modified by the identity that created it.

The policy set was consolidated from 18 overlapping policies to 9 clean policies. This was not cosmetic — overlapping RLS policies compose by OR, so a redundant permissive policy silently defeats a restrictive one. The consolidation was the fix, not a tidy-up.

Gotcha, documented because it cost time: the authenticated role does not apply to Anonymous Auth sessions in the way one would expect. Policies written against authenticated do not fire. auth.uid() is null in the anonymous context, which is the direct cause of the outstanding push_subscriptions bug (§14.1).

4.3 SMS OTP — live in production current

Registration calls the send-otp and verify-otp Edge Functions directly. The SMS_VERIFICATION feature flag has been removed from app/index.html.

⚠️ Operational consequence, unmitigated. There is no fallback path. If send-otp fails — including for insufficient Twilio balance — no new user can register on any surface. This is a single point of failure on a third-party balance. Either a fallback path or a balance alarm is required; neither exists today.

4.4 Lazy row creation current

ensureUserRow() fires only on a real action — report, validate, or register. It does not fire on app open. Rationale: a node that has never observed anything is not a participant, and creating a row for it pollutes the node table with entries that can never contribute weight.

4.5 Biometrics are a device lock, not authentication current

WebAuthn is implemented as a local device lock on the PWA. It does not authenticate the node to the server and produces no server-side assertion. This distinction is documented in code at the call site precisely because the UI affordance looks like authentication and a future maintainer would otherwise assume it is.

A separate work item exists on the "Usar Face ID / Huella" control, which currently shares a handler with the SMS send step. That is being addressed independently and is out of scope here.

5. The observation pipeline

An observation is a claim of the form "I was here, at this time, and I observed this." It enters the system identically regardless of channel.

  1. CAPTURE      client obtains GPS fix + timestamp + payload
  2. SUBMIT       POST to validate-event (never a direct table write)
  3. VERIFY       server computes presence weight against the anchor
  4. BIND         observation attached to event, with its weight
  5. RECOMPUTE    event confidence recomputed from all observations
  6. PROPAGATE    updated state pushed to subscribed clients

Steps 3 through 5 are entirely server-side. The client never computes weight and never asserts one. A client that submits a weight has that field ignored.

5.1 Why the client cannot be trusted with this

The client is under the attacker's control. It runs on the attacker's hardware, in a browser they can instrument, over an API they can call directly. Any presence check performed client-side is a suggestion. The only presence check that has meaning is the one performed on data the client submitted, by code the client cannot modify.

This is the reason validate-event exists as an Edge Function rather than as a direct table write with an RLS policy: RLS can answer may this identity write this row, but it cannot answer is this claim of presence physically coherent.

6. Presence verification — the cone

This is the mechanism that separates Jalibor from a reporting application. Confidence is not voted. It is computed from physically verifiable presence in space and time.

6.1 The principle

Every observation is weighed by how close in space and how recent in time it is to the event. Presence near the event, right now, carries full weight. Presence far away, or long ago, fades toward zero — never rejected, just weightless.

6.2 The deployed model current

The production implementation uses a piecewise cone rather than a smooth curve:

Parameter	Value	Meaning
`R`	1 km	Radius of full presence. Inside `R`, the geographic term is 1.
`v`	≈ 2.2 m/s	Rate at which the cone opens with elapsed time. Pedestrian speed.
Freshness half-life	≈ 20 min	Decay constant of the temporal term.

    w  =  w_cone  ×  w_freshness           w ∈ [0, 1]

    w_cone       = 1            if  d ≤ R + v·Δt
                 = 0            otherwise  →  enters as zero-weight
                                              distant corroboration

    w_freshness  = 2^(−Δt / 20min)

The cone metaphor is literal: at Δt = 0 the admissible region is a 1 km disc; as time passes, the region a genuine observer could have walked from expands at v, so the disc grows into a cone in (space, time).

6.3 Two measurement rules that are easy to get wrong

Both of these were bugs before they were rules.

Distance is measured against the immutable original anchor. Not the live centroid. If distance were measured against a moving centroid, each new observation would shift the reference point, and a coordinated group could walk the event across the map one observation at a time. The anchor is the position reported when the event was created and it never changes.

Δt is measured against the GPS fix timestamp, not the database insert timestamp. Insert time measures our latency, not the observer's presence. A slow request would otherwise be indistinguishable from a stale observation.

6.4 The continuous model, and the divergence design

The analytic model presented publicly — on the enterprise site, in the investor experience, and in the PMC specification — is the smooth form:

    w  =  e^(−d² / 2s²)  ·  e^(−λ·Δt)
          └ geographic ┘   └ temporal ┘

with web-visualisation parameters s = 1.05, α = 0.42.

⚠️ These are not the same function. The deployed model is a hard-edged admissibility cone with exponential freshness. The published model is a Gaussian in space with exponential decay in time. They agree in shape and invariants — monotone decay in both arguments, no rejection, weight bounded in [0,1] — and disagree in the transition region near the cone boundary, where the deployed model steps to zero and the continuous model tapers.

This divergence is stated rather than smoothed over. Resolving it is an open item (§14.3): either the implementation adopts the continuous form, or the specification adopts the piecewise form as normative and presents the Gaussian as the illustrative limit case.

6.5 Reading the cone visually

State	Colour	Meaning
Inside the cone	`#00D4FF`	near and recent → full presence weight
At the edge	`#5FE3FF`	distant or fading → partial weight
Outside	`#5A6B75`	too far or too old → near-zero weight
The event	`#FF3B3B`	at the apex of the cone

Axes: X = distance in space · Y = time since event · Z (height) = presence weight.

6.6 What does not happen at the boundary

There is no rejection. An observation outside the cone is admitted as zero-weight distant corroboration. It is stored, it is attributable, and it contributes nothing to confidence. This matters for two reasons: it preserves the record for later analysis, and it means the boundary is not an attack surface — there is no error state to probe for.

7. The confidence engine

Confidence is a saturating aggregation of presence weight:

    C  =  1 − e^(−α · Σw)

The saturation is the anti-manipulation property, and it is structural rather than defensive. Because returns diminish, flooding the network with reports does not manufacture certainty. The hundredth low-weight observation adds almost nothing. Reaching high confidence requires independent presence, and independent presence is expensive to fake in a way that volume is not.

7.1 The published scale

Independent nodes	Confidence band
0 – 1	0 – 14 %
…	…
75 +	90 – 100 %

This scale is legitimate to publish because it describes the design of the protocol — the configured relationship between node count and confidence — not a measurement of the world. That distinction is the operative test for every number in every Jalibor artifact.

7.2 Cluster coherence reduces, never boosts

When validating observations are geographically or temporally clustered in a way that suggests they are not independent, the weight of the cluster is reduced. There is no path by which coherence increases weight.

The asymmetry is deliberate. If coherence could boost, coordinating a cluster would be the optimal attack. Because it can only reduce, the optimal strategy for an attacker and the optimal strategy for an honest network are the same: be genuinely dispersed. An attacker who achieves genuine dispersal has, at that point, done the expensive thing.

7.3 Recompute, never increment

Confidence and contribution score are recomputed from the observation set. They are never incremented in place. An incremented counter drifts from its source and cannot be audited; a derived value can always be recomputed and compared. This principle also applies to every display value in every surface.

8. Anti-sybil: the barrier is identity, not position

The naive assumption is that GPS dispersal is the defence — that requiring observers to be spread across space makes coordinated attack expensive. It does not. Falsifying position is trivial. An attacker can produce a thousand well-dispersed GPS coordinates from a single machine at effectively zero cost.

What is not trivial is producing a thousand phone numbers that can each receive an SMS.

8.1 The cost model

Channel	Approx. cost per verification (LATAM)	Role
SMS	USD 0.10 – 0.15	The barrier. Long-term anti-sybil mechanism.
WhatsApp	lower	Convenience channel, not a barrier.

SMS was chosen over WhatsApp specifically because it costs more. The cost is the feature: it sets a floor on the price of a fake identity. A sybil attack at scale becomes a line item.

8.2 What was considered and rejected

Mandatory national-ID verification was rejected on three grounds: it contradicts the events, not people posture, it creates data-custody liability across every LATAM jurisdiction simultaneously, and — decisively — it does not stop the actual attack vector, which is a single actor with many cheap identities rather than one actor with a false identity.

9. Multichannel ingestion

Three channels, one pipeline. current

Channel	Transport	Notes
PWA	Direct HTTPS to Edge Functions	Full surface: map, observation, validation, profile
WhatsApp	Twilio webhook	Validation and lightweight observation
Telegram	Bot API webhook	Validation and lightweight observation

All three converge on the same validate-event verification path. A channel is a transport, never a trust level.

9.1 The 3-hour validation window

Validation requests are not issued for events older than 3 hours, and the window is enforced in all three channels.

The reasoning is a direct consequence of the freshness half-life. At a ~20-minute half-life, an observation arriving three hours after the event carries a weight on the order of 2⁻⁹. It cannot meaningfully move confidence. Asking a participant to validate something that cannot contribute wastes their attention and, worse, teaches them that validation does not matter.

This rule was derived empirically: a 13 % confidence reading was initially attributed to cluster effects, and measurement showed the actual cause was temporal decay — two validations had arrived 4,456 minutes after the event. The lesson recorded alongside the rule: measure before attributing.

9.2 WhatsApp

Twilio-based. Meta Business WhatsApp is deferred until funding; the current path is adequate for the channel's role.

9.3 Telegram linking current

Two link types, deliberately separated:

Personal link — a single-use token with a 15-minute TTL, binding a Telegram account to a node.
Public link — shareable, carries no binding capability.

Conflating them would mean a forwarded link could bind an attacker's Telegram account to someone else's node.

10. Data model

The tables that matter to the consensus path:

Table	Role
`events`	The event object. Immutable original anchor, category, derived confidence.
`observations`	Individual observations bound to events, each with a server-computed weight.
`nodes`	Pseudonymous participants. Reputation, contribution score.
`push_subscriptions`	Web Push endpoints per device.

10.1 Deliberate schema properties

No rejections table, and no negative weight. The absence is the invariant.
The anchor is a separate column from any derived centroid. They are never conflated (§6.3).
observations retains zero-weight rows. Distant corroboration is data.
Foreign keys were relaxed during auth hardening to accommodate lazy row creation (§4.4) without creating ordering dependencies at write time.

11. Security model

11.1 The three enforcement layers

Layer	Enforces
Edge Functions	Presence coherence. Can this claim be physically true?
PostgreSQL RPC	Consensus arithmetic. Weight and confidence computation, server-side.
Row Level Security	Ownership. May this identity touch this row?

Each answers a question the others cannot. RLS cannot evaluate physics; Edge Functions should not be the sole gate on row ownership.

11.2 What the client is allowed to do

Read public event state. Submit observations. Nothing else. Specifically, the client cannot: write to events directly, assert a weight, assert a confidence, or modify another node's rows.

12. Client surfaces

Four distinct sites in the repository. current

#	Path	Role	Note
1	`index.html`	Landing	Entry point at `ernih.github.io/JBL/`
2	`app/index.html`	The PWA	~324 KB single file
3	`web/index.html`	Web3 / DePIN site
4	`enterprise/index.html`	Enterprise site	~59 % shared with `app/`

12.1 Enterprise site — current structure (9 sections)

hero · pmc-3d (live Three.js PMC simulation) · problem · living (Static Report vs Living Consensus) · how · formula (Confidence Engine) · cone (interactive Presence Cone) · ecosystem · network.

Fully bilingual: 219 EN keys = 219 ES keys, zero untranslated elements.

12.2 Brand v3 current

Deployed and verified byte-for-byte across all four surfaces.

Token	Hex
Background	`#000000` / `#05070C`
Cyan primary	`#00D4FF`
Cyan light	`#5FE3FF`
Cyan dark	`#0098C4`
Event red	`#FF3B3B` (brand only, never UI alert)
Silver	`#90A4AE`
Ink	`#F0F4F8`
Dim	`#5A6B75`

The previous teal #41B4D3 is retired. Zero occurrences remain.

Typography: Syne 800 (display) · Space Grotesk (body) · JetBrains Mono (data/labels).

Isotype: parametric observer cloud (5 rings, 98 nodes, golden-angle rotation, seed 7 jitter) resolving to a red event core. Wordmark: traced letters with the isotype replacing the O. Sizing rule: dimension by width, never height — the isotype exceeds the cap-height box. Letter strokes use var(--jbl-ink), never currentColor.

12.3 i18n architecture

Single dictionary LANG = {en:{…}, es:{…}}. Never a duplicated English copy of the site.

data-i18n="key" → replaces textContent
data-i18n-html="key" → replaces innerHTML; mandatory where the string contains markup
setLang() walks both selectors and persists to localStorage

Known trap: strings generated at runtime by JS are invisible to the DOM-walking translator. Solved with a parallel SIM_I18N dictionary, a simT(key) helper, and a window.__pmcRefreshLang() hook that setLang invokes to redraw live labels.

13. Privacy and regulatory posture

13.1 LATAM as a set, not a country

All regulatory reasoning uses the strictest common denominator across LATAM — LGPD (BR), Ley 25.326 (AR), Ley 21.719 (CL), and regional equivalents. The system is designed to be deployable across the region without per-jurisdiction architectural forks. Any single country is a deployment target, never the design frame.

13.2 Data minimisation as architecture

Events, not people. No identity is bound to an event record.

Multimedia was cut from the MVP following regulatory analysis. Consequences applied in code: the camera permission was removed entirely; the microphone is retained for voice observation. Removing the permission rather than merely not using it is the point — an unused permission is still a disclosure obligation and still an attack surface.

13.3 Proportionality of legal notices

Individual legal notices may each pass review while their accumulation fails. Total notice volume is benchmarked against comparable applications (Citizen, Waze) before shipping. A consent wall that is individually defensible and collectively hostile is a failure.

13.4 Technical access gating

Technical Brief, Technical Documentation, and Request Demo are gated behind a verification form (name + work email). No technical artifact is directly public. Public social presence is a single channel: X → @JaliborLabs.

14. Open items

14.1 Bugs current

#	Item	Detail
1	`push_subscriptions` RLS	INSERT policy uses `auth.uid()`, which is null under Anonymous Auth → 403, subscriptions never persist. Fix: `WITH CHECK (true)` for the anon role.
2	`events.confidence` type	Double precision vs integer mismatch.
3	Duplicate event pins	Two pins ~25 m apart in the demo. Deduplication rule needed.
4	`enterprise/index.html`	Theme blocks declared twice → `EVENTS is not defined`, `confVal is not defined` in console.
5	SQL hygiene	Cleanup with pre-delete diagnosis and post-delete recalculation.

14.2 Operational

Twilio balance is a hard dependency with no fallback (§4.3). Highest-severity operational item.
meta apple-mobile-web-app-capable deprecated → add mobile-web-app-capable.
/setname in BotFather → "Jalibor".

14.3 Architectural limitations, stated plainly

GPS spoofing is not protected against. A determined attacker can falsify position. The mitigations that exist — SMS identity cost (§8), saturating aggregation (§7), cluster reduction (§7.2) — raise the price of a large-scale attack but do not detect a single spoofed fix. Device attestation and cross-corroboration are the intended answer and are protocol design, not an implementation task yet [PROPOSED].

The presence model has two forms (§6.4). Unresolved.

No fallback identity path. Single third-party dependency for all new registration.

15. Where the architecture goes next

In priority order, as the system currently stands:

Twilio balance and a registration fallback. Nothing else matters if new users cannot register.
RLS and type fixes (§14.1, items 1–2).
Event deduplication (§14.1, item 3).
Resolve the presence model divergence (§6.4) — implementation and specification must agree before the specification is published externally.
GPS attestation design (§14.3) — the largest open protocol question.
Hybrid node types — camera, IoT, and AI observers entering through the same interface. This is the step that makes §2's "AI is an observer" claim operational rather than architectural.

Appendix A — Parameter register

Parameter	Value	Where
`R` — full presence radius	1 km	Deployed cone
`v` — cone opening rate	≈ 2.2 m/s	Deployed cone
Freshness half-life	≈ 20 min	Deployed cone
Validation window	3 h	All three channels
Telegram link TTL	15 min	Personal linking token
`s` — Gaussian spatial scale	1.05	Web visualisation
`α` — saturation coefficient	0.42	Web visualisation
Confidence scale	0–14 % → 90–100 %	0–1 → 75+ nodes
SMS cost	USD 0.10–0.15	LATAM, per verification

Every value above is a configured parameter or a third-party price. None is a measurement.

Appendix B — Working method

Fetch the live file from raw.githubusercontent.com/Ernih/JBL/main/<path> before patching. Repository copies in project storage are stale and patching from them reverts production work.
Apply changes with exact-match scripts guarded by a "1 occurrence expected" assertion.
Validate every <script> block with node --check and new Function(). Target: ALL CLEAN.
No em dashes inside JS strings. They break files silently. Substitute plain hyphens.
Verify that the new thing is present and that the old thing is still there.
Audit the whole file, not the part visible in the screenshot.
One change at a time, with explicit verification.
Cache-bust with ?v=N.

Appendix C — Glossary

Term	Definition
PMC	Presence Mesh Consensus. The protocol: consensus about physical events from spatiotemporal presence verification. Specified in `pmc-specification-v0.3.md`. Formerly also called JCP; that name is retired.
Reference implementation	Jalibor. The system this document describes. Conformant to PMC, but not definitional of it.
Anchor	The immutable original reported position of an event. Distance reference.
Presence weight	`w ∈ [0,1]`, the contribution of one observation, computed server-side.
Distant corroboration	A zero-weight observation from outside the cone. Recorded, not rejected.
Confidence	`C ∈ [0,1]`, saturating aggregation of presence weight. Decays without corroboration.

End of architecture document — v2.1.