@sonordev/contracts 2.17.0 → 2.20.0

package/CHANGELOG.md

@@ -1,5 +1,45 @@
 # Changelog
 
+## 2.20.0
+
+- Publish the `resonance`, `resonance-constants` and `signal-experiments` entries with matching CommonJS, ESM and TypeScript surfaces. Add the documentation manifest used by sonor.dev. These validation contracts grant no campaign approval or spending authority.
+
+- Bind current Meta configuration review to the existing semantic definition digest plus a nondecreasing audit revision. Add required native `currentDefinitionDigest` metadata so metadata-only saves can preserve multiple unchanged channel configurations. Original snapshots stay immutable; exact prepared-plan, approval and native root fences remain unchanged.
+
+- Add pure native measurement bootstrap save/current/snapshot/response contracts and one deterministic page projection using existing semantic digest bytes. Native page resources retain UTC millisecond revisions; rule revisions use full existing evidence digests. Project/site CAS, actual protected writer and one read-only native freshness resolver remain separate adoption requirements.
+- Add pure Meta configuration save/snapshot/view/response contracts, exact existing-audience or admitted-setup mappings, immutable friendly review material, shared digest/projection helpers, minimal optional mandate feed selection and post-acceptance original feed review. Preserve the raw existing mandate-draft response and no-feed request bytes. Saved profile references require actual persisted operation IDs and integer configuration revisions; parsing grants no native capability or approval.
+- Add closed explicit `provider_managed` Meta age intent alongside unchanged absent, omitted and bounded behavior. Actual first same-root PAUSED creator observation and unchanged activation comparison remain native owner work; existing consumers must explicitly support the new branch before adoption.
+
+- Add an optional original Meta website-visit feed grant and a closed internal `deliver_website_visit` command through the existing Resonance parser and digests. Preserve omitted legacy fields and require explicit native feed authority; parsing doesn't authenticate a producer or permit manual origination.
+- Add same-occurrence reported path and Meta cookie observation shapes, one fixed SDK observation policy and canonical semantic configuration/profile digest helpers. Add original-time checks with an inclusive five-minute local freshness bound and zero future allowance. These are Sonor rules, not Meta acceptance guarantees; native capture, consent, admission and delivery remain separate.
+- Represent explicit omitted or bounded original Meta age selection. Absent fields retain legacy bytes and don't choose defaults. Actual policy, compiler and normalized readback support remain adapter responsibilities.
+
+- Add a closed Google qualified-conversion delivery command and explicit original mandate operation. Reference one original Google channel and a persisted conversion ID. Optional plan, mandate and time context checks public grant consistency and the original prepared definition revision; private facts, native receipts, current consent and final admission remain server-owned. Existing launch grants never expand automatically.
+
+- Add closed finite Meta candidate policy, lifecycle evidence and one-action decision variants through the existing Resonance entry. Reference original candidate channel IDs, preserve mature allocation, and bind later graph evidence without a digest cycle. Fixed exploration explicitly has no performance-decision policy. Optional actual evidence/plan arguments check cross-object scope and action consistency; native funding and admission remain server-owned.
+
+- Add optional, closed `clickIdentifiers` to page-view measurement occurrences. Accept exactly one bounded `gclid`, `gbraid` or `wbraid`; other occurrence kinds reject it. Export its parser, type and JSON Schema. Identifiers describe observed lineage and grant no conversion or provider authority.
+
+- Add strict Google configuration draft, snapshot, view and review contracts, one canonical projection and a digest-input helper. Prepared Google Search previews require either actual existing-goal evidence or bounded one-action setup intent for creation after the same mandate; other channels use explicit `null`. Require the explicit historical `qualified_at_observation_v1` provider signal profile, distinct from current Sonor outcome counts. Draft declarations stay bound to their campaign and creative scope; parsing grants no provider or approval authority.
+
+- Add strict command-preparation request and response parsers. Preparation reports existing mandate or current owner approval requirements and never grants authority. Add `@sonordev/contracts/resonance-constants` for browser wire literals without campaign schemas.
+
+- Add canonical Signal experiment create/update parsers and bounded Resonance audience/experiment management commands. Add reviewed public source-marker fields and the explicit first-party last-touch attribution model. These parsers validate wire data and grant no approval or provider authority.
+
+- Add `@sonordev/contracts/resonance`: strict campaign, account capability, prepared-plan, mandate lookup, command, receipt, measurement and consent boundaries for connected campaign operations. Money uses exact decimal-string micros with checked provider-unit conversion. Parsing validates data and scope; it never grants advertising or spending authority.
+- Retain the 2.19 review-photo presentation exports and all existing contracts.
+
+## 2.19.0
+
+- Add an optional per-review photo presentation to `@sonordev/contracts/broadcast-layouts`: `REVIEW_PHOTO_PRESENTATIONS`, `ReviewPhotoPresentation` and `isReviewPhotoPresentation` support the explicit `background` choice. Input consumers handle an omitted choice by preserving the saved value and `null` by clearing it to automatic. Existing automatic layouts, composition seeds and variation draws are unchanged.
+- Keep the decision-role entry and all other published contracts behavior unchanged.
+
+## 2.18.0
+
+A minor release: one new entry, `@sonordev/contracts/decision-roles`. Every other entry is unchanged.
+
+- **What a job title says about a buying decision.** `DECISION_ROLES` is the four parts a person can play (`owner`, `decision_maker`, `influencer`, `gatekeeper`), strongest first, and `decisionRoleForTitle(title)` returns the one a title names, or `null` when it names none. The role comes from the title alone, by eight rules read in order with the first match deciding, so "Vice President of Sales" is a decision maker, "Executive Assistant to the CEO" is a gatekeeper and "Marketing Coordinator" is an influencer. "Principal" is an owner unless it names a job, so "Principal Engineer" has no role. A title is read whole (it isn't split on "&" or "/") and only its first 200 characters count. `DecisionRole` is the type. Anything that finds the people on a company's website can import it, so two scans of the same page can't give one person two roles.
+
 ## 2.17.0
 
 A minor release: one new entry, `@sonordev/contracts/crm-disposition`. Every other entry is unchanged.

package/README.md

@@ -19,7 +19,7 @@ pnpm add @sonordev/contracts
 | `@sonordev/contracts/seo-pages` | Which `seo_pages` row a path resolves to on a multi-site project | the Sonor API, Signal, site-kit's sitemap sync |
 | `@sonordev/contracts/seo-meta` | Whether a title or description is fit to ship | site-kit, Signal's SEO gate |
 | `@sonordev/contracts/llms` | llms.txt sanitizers, the word-safe cut they use (`clipAtWordBoundary`), what each page line says (`pickLlmsPageDescription`: summary, curated meta, served meta, schema description, then a cleaned scrape; `llmsPageTitle`, `isLlmsListablePage`, `groupLlmsPages`, `selectLlmsPages`) and the contract version | site-kit, the Sonor API, Signal's schema validation |
-| `@sonordev/contracts/forms` | The honeypot policy | site-kit forms, the Sonor API's form intake |
+| `@sonordev/contracts/forms` | Shared form validation helpers | site-kit forms, the Sonor API's form intake |
 | `@sonordev/contracts/fleet` | The fleet heartbeat's wire shape | site-kit, the Sonor API |
 | `@sonordev/contracts/slots` | Slot payload signing, contract v2 (HMAC; Node only). Signs and verifies v1 for older site-kit releases | the Sonor API, site-kit on the server |
 | `@sonordev/contracts/slot-content` | What a slot of each kind may hold (`normalizeSlotValue`), safe links, the rich-text parser. No `crypto`, so browsers can import it | the Sonor API, site-kit, the dashboard editor |
@@ -41,6 +41,10 @@ pnpm add @sonordev/contracts
 | `@sonordev/contracts/funnels` | Incomplete drafts, launch definitions, command/readiness/receipt schemas, bounded public pages and presentation-only brand overrides | Sites, APIs, UI and agent adapters share the same rules |
 | `@sonordev/contracts/inbox` | Which inbox cards are decisions a bulk action leaves alone (`isDecisionCard`, `DECISION_INSIGHT_TYPES`) | Signal's inbox decides what "Mark all read" and "Dismiss all" may touch, the dashboard previews the same result before the write |
 | `@sonordev/contracts/crm-disposition` | What a rep's call outcome (positive, negative or left voicemail) changes on a prospect: the call's outcome and sentiment, the contact's stage, the company's status, today's reminder and outreach (`dispositionTransitions`), and the reasons a negative outcome carries | the Sonor API applies an outcome, the dashboard's calling screen offers the same three buttons and reasons, the sales extension stops flipping a company on dial |
+| `@sonordev/contracts/decision-roles` | The part a job title says a person plays in a buying decision (`DECISION_ROLES`: owner, decision maker, influencer, gatekeeper), read from the title alone by `decisionRoleForTitle` | the Sonor API's site-people scan and Signal's site-people scout read the same map |
+| `@sonordev/contracts/resonance` | Campaign, consent, measurement, plan, mandate and command parsers, types and JSON schemas | Sites, APIs and the dashboard share the same wire rules |
+| `@sonordev/contracts/resonance-constants` | Small browser-safe measurement wire constants | Browser readers that don't need campaign schemas |
+| `@sonordev/contracts/signal-experiments` | Shared Signal experiment create and update validation | APIs and the dashboard use one experiment boundary |
 
 ## Focus closing artwork
 
@@ -149,6 +153,65 @@ dispositionTransitions('negative', { reason: 'do_not_call' })
 change incompatibly. The wire values (the three outcomes and five reasons) are
 stored and sent, so they don't change.
 
+## Decision roles
+
+When a company's website lists its people, what each job title says about a
+buying decision has to be read the same way wherever the list is built.
+`decisionRoleForTitle` is that rule, written once, so a person can't be an
+influencer in one scan and an owner in another. The role comes from the title
+the page gives and never from a model's opinion: a model can find the people,
+and code decides the role.
+
+```ts
+import { DECISION_ROLES, decisionRoleForTitle } from '@sonordev/contracts/decision-roles'
+
+DECISION_ROLES                                          // ['owner', 'decision_maker', 'influencer', 'gatekeeper']
+decisionRoleForTitle('Vice President of Sales')         // 'decision_maker'
+decisionRoleForTitle('Executive Assistant to the CEO')  // 'gatekeeper'
+decisionRoleForTitle('Marketing Coordinator')           // 'influencer'
+decisionRoleForTitle('Principal Engineer')              // null
+```
+
+The first rule that matches the title decides, in this order:
+
+| Order | The title says | Role |
+|---|---|---|
+| 1 | an executive, administrative, office or personal assistant, "assistant to", secretary, receptionist, front desk | `gatekeeper` |
+| 2 | vice president (VP, SVP, EVP, AVP) | `decision_maker` |
+| 3 | owner, co-owner, founder, co-founder, proprietor, president, CEO, chief executive, managing, senior, name or equity partner, a lone "Partner", or "Principal" that isn't a job | `owner` |
+| 4 | a chief of something else (COO, CFO, CTO, CMO, "Chief ... Officer") | `decision_maker` |
+| 5 | general manager (or GM), director, operations manager, estimator, estimating manager, project manager, superintendent | `decision_maker` |
+| 6 | office manager, administrator, administrative, admin | `gatekeeper` |
+| 7 | marketing, HR, human resources, recruiting, talent acquisition, sales, business development | `influencer` |
+| 8 | coordinator | `gatekeeper` |
+
+- **Order is the meaning.** "Vice President of Sales" is a decision maker, not
+  an owner because it says president and not an influencer because it says
+  sales. "Marketing Director" is a decision maker, because director comes
+  before marketing. "Marketing Coordinator" is an influencer, because
+  marketing comes before coordinator. "Executive Assistant to the CEO" is a
+  gatekeeper, because the assistant rule comes before the CEO rule.
+- **"Principal" is an owner unless it names a job.** "Principal" alone is an
+  owner. "Principal Engineer", "Principal Architect", "Principal Consultant",
+  "Principal Designer", "Principal Developer" and "Principal Analyst" say
+  nothing about ownership, so they have no role.
+- **A title is read whole.** A title that names two jobs isn't split, and the
+  strongest role doesn't win; the first rule above that matches does. "Owner &
+  Office Manager" is an owner. "Receptionist & Owner" is a gatekeeper.
+- **"Assistant" alone isn't a gatekeeper.** "Assistant Project Manager" and
+  "Assistant General Manager" are decision makers, as the manager rules read
+  them. "Assistant to the Project Manager" is a gatekeeper.
+- **No title or no match is `null`.** "Technician", a bare "Manager",
+  "Accounting Manager", an empty string, whitespace, `null`, `undefined` and
+  anything that isn't a string all say no role. The map doesn't guess.
+- **Case, `&` and periods don't matter.** "C.E.O.", "FOUNDER & CEO" and
+  "Vice-President" read the same as their plain spellings.
+- **Only the start of a title is read.** Titles come off scraped pages, so
+  the first 200 characters decide and the rest is ignored.
+
+The four role values are stored and sent, so they don't change. `DECISION_ROLES`
+lists them strongest first, which is the order a screen should rank them in.
+
 ## Schema placeholders
 
 `schema-placeholders` finds the parts of a JSON-LD value that a template left
@@ -793,6 +856,7 @@ import { createHash } from 'node:crypto'
 import {
   ARTICLE_COVER_LAYOUTS, CARD_LAYOUTS, isCardLayoutId, normalizeArticleCoverLayout,
   normalizeReviewCardVariation, reviewCardVariationFromDigest, reviewCompositionSeed,
+  REVIEW_PHOTO_PRESENTATIONS, isReviewPhotoPresentation,
 } from '@sonordev/contracts/broadcast-layouts'
 
 CARD_LAYOUTS                                // ['stacked', 'headline', 'split', 'anchor']
@@ -801,6 +865,9 @@ isCardLayoutId('stacked')                   // true: an old post still reads
 normalizeArticleCoverLayout('stacked')      // 'anchor'
 normalizeArticleCoverLayout('split')        // 'headline'
 normalizeReviewCardVariation('spotlight')   // 'signature'
+REVIEW_PHOTO_PRESENTATIONS                 // ['background']
+isReviewPhotoPresentation('background')    // true
+isReviewPhotoPresentation(null)            // false: a clear operation is handled by the caller
 
 // On the server: a review's composition, stable for its identity.
 const digest = createHash('sha256').update(reviewCompositionSeed(projectId, reviewId)).digest()
@@ -829,6 +896,13 @@ reviewCardVariationFromDigest(digest)       // 'signature' or 'frame'
   as Signature and anything unknown as the default, Signature.
   **`isReviewCardVariation`** is the strict check for a request that must
   name a drawn one.
+- **`REVIEW_PHOTO_PRESENTATIONS`** lists explicit per-review photo choices:
+  `background` places the primary photo behind the review text. The
+  `ReviewPhotoPresentation` type and `isReviewPhotoPresentation` guard share
+  that supported set. The guard accepts explicit values only; input consumers
+  handle omission (preserve a saved choice) and `null` (clear it to automatic)
+  separately. Existing records without a choice keep their deterministic
+  composition; presentation doesn't change the seed or variation draw.
 - **A review's composition never moves.** It's drawn from the SHA-256 of
   `reviewCompositionSeed(projectId, reviewId)`, never from anything a person
   can edit. `reviewCardVariationFromDigest` reads the first four bytes
@@ -1086,3 +1160,442 @@ Use `parseFunnelCreateArgs`, `parseFunnelUpdateArgs`, `parseFunnelRevisionArgs`,
 `parsePublishedFunnelPage` refuses private definition fields and unsafe asset URLs. It supports bounded text paragraphs and bullet lists, with a managed form slug and canonical campaign identity. `managedFunnelPath` reserves `/f/:slug`; a consuming site must opt in and verify its actual routes.
 
 `parseFunnelReadiness`, `parseFunnelOperationReceipt` and the detail/catalog/preview parsers validate bounded response envelopes. Operation receipts bind the exact command target and approved action, and always report zero messages sent by the configuration command. Preview and published-version detail parsers preserve the exact launch or rollback evidence.
+
+
+## Adopting 2.20.0
+
+Use the same contracts version in every application that exchanges Resonance
+payloads. This release includes the 2.19 review-photo presentation exports and
+adds the Resonance and Signal experiment entries. Existing package subpaths stay
+available. Import a specific entry rather than the package root.
+
+```ts
+import { parseMoney } from '@sonordev/contracts/resonance'
+
+const budget = parseMoney({ currency: 'USD', amountMicros: '1250000' })
+```
+
+The parsers validate wire data. They don't approve a campaign, authorize spending
+or confirm provider delivery. Keep those checks in the application that owns the
+action. Deploy accepting server parsers before enabling new browser fields.
+
+## The resonance contract
+
+Import pure parsers, types and JSON schemas from `@sonordev/contracts/resonance`.
+`parseResonanceCampaignDraft` accepts bounded incomplete setup; `parseResonanceCampaignDefinition`
+requires resolved goals, resources, destinations, channels and budget. Existing funnel,
+Broadcast, Outreach, Files, brand and experiment records retain ownership. Nested
+references must match the campaign's project and owned-site scope. Server lookups
+must still validate ownership, current revisions, policy and actual permission.
+
+`Money` is `{ currency: 'USD', amountMicros: '1250000' }`, exactly 1.25 USD.
+`parseMoney`, `addMoney`, `moneyToProviderUnits` and `moneyFromProviderUnits` use
+integer arithmetic. Never pass amounts through `Number` or assume every currency
+uses cents. Conversion requires the verified provider/account exponent (0, 2, 3 or
+6) and native limit; fractional units, overflow and currency mismatch fail.
+Supported currency codes are exported as `RESONANCE_CURRENCIES`; actual advertiser
+eligibility, minimum budgets and delivery semantics remain provider checks.
+
+The initial paid profiles are `google_search` and `meta_retargeting`, distinct
+from provider IDs `google_ads` and `meta_ads`. They are closed plans, not arbitrary
+provider JSON or a claim to support every campaign type. Prepared plans bind exact
+ordered creative copy/media/crop references, destinations, budgets, goal/policy
+revisions and server-owned compiled manifest references. `resonancePlanIssues`
+reports blocked, missing or stale capabilities without turning them into success.
+
+`parseResonanceMandateApprovalPayload(value, target)` validates the exact business
+payload and project/campaign target. It doesn't approve anything. Resolve original
+principal and approval provenance through the existing Action Ledger; compute and
+verify the server digest over `resonanceMandateDigestInput` before admitting effects.
+The command digest input similarly canonicalizes only parsed command fields.
+Launch/update/resume and optimization require exact plan/mandate lookups. Safety
+pause/finish/reconcile commands require root revision and idempotency identity but
+no fresh creative approval, so stale creative evidence cannot prevent a stop.
+
+An immutable `PreparedPlan` is stored as an existing campaign version; it is review
+evidence, not approval authority. Receipt state and unresolved exposure remain
+separate from approval. An uncertain provider admission requires reconciliation
+before retry; it must not release liability or repeat creation automatically.
+
+Metric observations distinguish observed zero from unknown, insufficient, delayed
+and unavailable values, retain window/timezone and native-unit evidence, and use
+exact counts/money/ratios. Consent and conversion parsers validate scoped evidence;
+a browser cannot mint a trusted lead by passing validation. Accepted source rows,
+current consent/withdrawal and experiment exposure must be verified server-side.
+No scripts, credentials, cookies or customer personal data belong in these DTOs.
+
+
+The save/binding/accept command parsers use the same strict wire rules. Updates
+require an expected root revision; root creation can omit it. Account bindings
+select existing provider resources, never credentials. Optimizer evidence and
+immutable decisions have separate parsers: they retain unknown tracking/power
+checks, exact before/after allocations and remote snapshot identities. Resolve
+minimum evidence, lag, cooldown and mandate coverage from the referenced frozen
+policy on the server. Parsed metrics or an actionable decision alone never grant
+spending authority. A blocked or no-op decision cannot carry allocation effects.
+
+
+Public measurement configuration is a separate closed DTO. It carries only typed
+Google Ads tag/Meta pixel identifiers, permitted resource rules and basic consent
+policy. A measurement occurrence is a view, explicit interest or experiment
+exposure; it cannot declare an accepted conversion. Consent updates preserve
+unknown, denied and withdrawn states. These parsers don't load any tags, collect
+browser data or turn a reported grant into server-verified permission. The browser
+runtime and server evidence/withdrawal checks must implement those controls.
+
+Page-view occurrences can include optional `clickIdentifiers`, with exactly one
+closed shape: `{ gclid: string }`, `{ gbraid: string }` or `{ wbraid: string }`.
+`parseResonanceClickIdentifiers`, `ResonanceClickIdentifiers` and
+`RESONANCE_CLICK_IDENTIFIERS_JSON_SCHEMA` share that boundary. Values contain
+1 to 1024 characters, with no whitespace or control characters. This is the
+application's transport bound. Other occurrence kinds reject the field.
+The browser reads the current URL only after the required advertising grants
+and scoped proof are available. An observed identifier doesn't authenticate a
+paid click. The server must verify the same subject, site, current consent and
+actual form occurrence before using it for conversion matching. Identifiers
+don't belong in public configuration, receipts, results or logs. Deploy the
+accepting server parser before enabling browser emission.
+
+Initial acceptance uses only `{ expectedRevision, ledgerActionId }`. The server
+loads the approved native payload and current kill state and returns the canonical
+mandate reference. Clients must never guess a kill revision to construct authority.
+
+
+Managed definitions contain the closed `optimization.policy`; prepared plans freeze
+an identical `resolvedEvidencePolicy`. Initial inline policies have `sourceRef: null`.
+A genuine existing source can supply optional provenance, but a new campaign doesn't
+need a synthetic experiment, self-referencing plan or new policy table. The first
+algorithm is explicitly observational qualified-lead CPQL allocation with approved
+maturity, coverage, uncertainty, attribution, lag and cooldown values. Executable
+allocation and current source/mandate admission remain server-owned.
+
+### Finite preapproved Meta candidates
+
+The optimization policy also supports the closed `finite_meta_candidates_v1`
+branch with `decisionKind: 'preapproved_candidate_operation'`. One policy
+variant belongs to each original plan. The existing mature allocation branch
+keeps its meaning and shape.
+
+The finite policy uses `candidateChannelIds` to reference original Meta channels
+in the same definition. Their existing creatives, account, site, independent
+adset lifetime cap and original budget flight remain authoritative. The policy
+doesn't copy those inputs or contain compiled graph hashes. It records an exact
+reviewed order and schedule, one activation per candidate, concurrency, allowed
+actions, a typed exploration ceiling, tracking requirements and hard stops.
+`performanceDecisionPolicy` is explicitly `null`: this profile supports fixed
+exploration and approved safety stops, with no measured winner, adaptive pruning,
+budget increase, promotion or causal A/B claim.
+
+Preparation resolves the original graphs and binds them with the policy in the
+existing review digest. The existing mandate seals that review. Later evidence
+and decisions reference the resulting graph identities; their hashes never feed
+back into the definition policy. No new policy registry or mandate field is used.
+
+`ResonanceFiniteMetaCandidatePolicy`, `ResonanceFiniteMetaCandidateEvidence` and
+`ResonancePreapprovedCandidateOperationDecision` narrow the existing generic
+types. Their parsers, JSON Schemas and digest helpers share the existing
+`resonance` entry. Cold lifecycle evidence records unobserved measurement as
+`null`, with no borrowed donor outcomes or invented mature zero. An actionable
+decision carries exactly one `materialize_and_activate`, `activate_held` or
+`pause_candidate` action. Blocked and no-op decisions carry none. These decisions
+don't carry mature adjustments or a fabricated zero-to-cap transfer.
+
+Pass the actual prepared plan as the optional second argument to
+`parseResonanceOptimizationEvidence` to check original public scope, manifest,
+cap and flight. Pass actual evidence and, when available, that plan as the second
+and third arguments to `parseResonanceOptimizationDecision` to check policy,
+action, fixed order, freshness and commitment-reference consistency. Parsing a
+standalone object checks its closed shape; it can't authenticate referenced rows
+or establish approval. Servers must load and verify the actual accepted plan,
+native claim, current permission and protected evidence before admission.
+
+The API and database reserve the full independent cap before the first create.
+Activating an already paused candidate adds no new exposure only when its exact
+original physical commitment is already fully held. Resource presence or a
+reference alone doesn't prove that condition. Pause and donor decreases don't
+release old holds; uncertain effects retain their original key and reconcile.
+The public optimize command and existing Ledger workflow are unchanged.
+
+Provider spend, clicks and impressions retain their own `provider_aggregate`
+counting unit and `provider_reported` attribution. First-party qualified-cohort
+observations keep the original objective's counting unit and attribution model.
+They aren't interchangeable evidence, and neither enables a performance
+decision in this fixed profile.
+
+Ordinary optimize actions, including an explicitly allowed candidate pause,
+remain inside the current policy and mandate expiry. At or after expiry,
+creation and activation stop; any needed pause uses the existing current-owner
+safety pause or escalation path. This contract doesn't create post-expiry
+permission or a second stop-validity clock.
+
+Public measurement transport uses the dedicated `X-Sonor-Resonance-Subject`
+header. Config reads do not issue identity. Only an explicit preference action
+can receive `subjectProof`, `expiresAt`, `currentConsentRevision` and the four
+purpose receipts. This is an opaque scoped proof, kept in browser memory. Proof expiry isn't
+consent expiry and must not force recurring consent prompts. Valid current CMP
+state may support scoped proof renewal/resumption through the authoritative API;
+until a valid proof is available, exports stay off. Config itself never bootstraps identity.
+`expectedConsentRevision` atomically fences the complete subject preference batch.
+The browser must discard stale grant replies, stop immediately on withdrawal,
+and never replay pre-consent events or bootstrap identity on config/page load.
+These contracts describe evidence, not an implemented transport or real-person identity.
+
+
+Tracking-only legacy campaign views retain revision zero; managed campaigns require
+at least revision one. Creation can adopt a tracking root at zero, but updates need
+a managed revision. Unknown admission in any child forces reconciliation and cannot
+be hidden by a failed root label or retry advice. Known reconciled/rejected work
+may still retry the same original operation when the server authorizes it.
+
+`parseResonanceSubjectRenewCommand` accepts only current consent/config/policy
+revisions. Renewal rotates a proof without granting or changing consent. It requires
+the scoped subject transport and current server/CMP checks; it isn't permission to
+bootstrap identity from a config read or recover someone else's receipt.
+
+
+Public renewal includes schema version and the asserted project/site envelope as
+well as current revisions; the server resolves and verifies that scope from proof
+and credential. Finite allocation horizons carry verified UTC start/end, timezone
+and source revision, so eligible total/lifetime budgets can be compared on the
+same actual period without relabeling daily averages as hard lifetime caps.
+
+`cpqlMissingOutcomeBound` computes the named observational sensitivity method from
+trusted unique-contact totals: eligible `n`, fully resolved attribution/dedupe/final
+qualification intersection `c`, and qualified subset `k`. It returns the ceiling of
+`10000*(n-c)/(2*k+n-c)`, or unknown when no positive source universe exists. This
+isn't statistical confidence, causal lift or permission to inject counts from a
+browser. API source producers must verify the complete universe and spend period;
+without that witness, the evidence bound remains unknown. Coverage stays separate.
+
+### Successor management and attribution fields
+
+The local 2.20 candidate adds `@sonordev/contracts/signal-experiments` as the
+single parser for the existing Signal create/update payload. It exports
+`parseSignalExperimentCreate`, `parseSignalExperimentUpdate`, their types and
+JSON Schemas. Both operations check unique variant keys and the existing
+weight-sum tolerance of 0.01. Percentages must be finite and within 0 to 100.
+Optional allocation and targeting defaults remain the existing service's job.
+Parsing doesn't grant access or select a variant.
+
+`/resonance` adds audience draft save and experiment create/update, lifecycle,
+complete and link command parsers. Each managed experiment command requires
+`expectedRevision` and `idempotencyKey`. Audience drafts reference the current
+measurement config's resource rule IDs. The server resolves their scope and
+provider retention limit. Saving a draft uploads no people or audiences.
+
+Public source markers use the `sonor_source` parameter and bounded
+`rsm1.<claims>.<signature>` format. A prepared channel preview can carry an
+`attributionMarker`; its destination URL must contain exactly that reviewed
+marker. An occurrence can carry the bounded `sourceMarker` value. The pure
+parser checks format and URL coherence. The server verifies the signature,
+purpose, accepted immutable plan and actual resource scope.
+
+`first_party_last_touch_marker_v1` describes server-recorded first-party source
+mapping under the reviewed attribution window. It doesn't establish a paid
+click, a human visit or a causal effect. Unresolved source linkage stays
+unallocated. The existing resource, audience-rule and experiment-reference
+readers are also exported so owner projections can use the same validators.
+
+Qualified-lead prepared plans require a non-null `resolvedQualificationRule`.
+Other objectives carry an explicit null. The objective keeps the selected
+`qualificationRule`; the prepared projection shows its actual CRM project ref,
+`crmVariant`, native `ladderSnapshot`, eligible form and cohort boundaries.
+`semantic_key` and native preset stage IDs can be null. The parser preserves
+those native values and never manufactures a stage UUID or infers qualification
+from a stage's position or won/lost flag.
+
+The three selected stage partitions must be disjoint and exhaust the resolved
+native ladder. The public projection must match the selected partitions, native
+ref, source form, counting unit and maturity delay. API persistence resolves one
+canonical witness and uses that same object for internal resource evidence and
+public review. The server must verify its actual source and digest. These shape
+checks don't establish that a caller supplied genuine database rows.
+
+`PreparedPlan.expiresAt` is an initial acceptance freshness deadline. Continuing
+an already accepted campaign uses its current native mandate and budget limits,
+with current resource and capability checks. The pure initial-readiness helper
+doesn't replace those authority checks.
+
+### Preparing a campaign command
+
+`parseResonanceCommandPrepareRequest` reads only `expectedRevision` and `idempotencyKey`. The API resolves the accepted plan, current resources and authority for launch, update or resume. `parseResonanceCommandPrepareResponse` reads `{ command, covered, approvalRequirement, reasonCodes }`, where `command` may be `null` and `approvalRequirement` is `existing_mandate`, `current_owner` or `null`. A covered command still needs its required native approval and claim. Resume after a pause requires the current owner's approval through the existing action ledger.
+
+`@sonordev/contracts/resonance-constants` exports `RESONANCE_SUBJECT_HEADER`, `RESONANCE_SOURCE_MARKER_PARAMETER` and `RESONANCE_ATTRIBUTION_MODEL` without loading campaign schemas. The main Resonance entry re-exports these same literals. Browser adapters can use the constants entry when they don't need a parser.
+
+### Delivering a qualified Google conversion
+
+The existing `ResonanceCommand` union adds `operation: 'deliver_conversion'`. It requires the usual schema version, campaign, prepared plan, review digest, expected revision, idempotency key and mandate reference, plus `channelIds` with exactly one original Google channel and `conversionId` for the persisted canonical qualified fact. The command carries no click identifiers, personal data, provider payload, values, timestamps, native destination or approval flags.
+
+The original mandate must explicitly include `deliver_conversion` in `allowedOperations`. A launch-only grant doesn't gain delivery permission. The existing original review binds the goal, source, qualification witness and Google configuration; there's no second delivery policy object. The initial profile is `qualified_at_observation_v1` for one managed-form qualified source and one destination. Existing goals with multiple actions are rejected for delivery. Cross-account action ownership remains unsupported.
+
+`parseResonanceCommand(value, { preparedPlan, mandate, now })` optionally checks those actual parsed objects for original scope and prepared definition revision, goal, budget, account, site, single-action Google profile and the original dispatch window. The one-argument call remains shape validation. An accepted plan's initial freshness deadline doesn't create a reporting tail: new dispatch must remain within its original mandate and budget window. Ordinary delivery stops after expiry; read-only receipt reconciliation doesn't resend it.
+
+These checks don't authenticate a persisted fact, current principal, kill or finish state, qualification, consent continuity, native claim or export deduplication. The server must verify the protected same-root goal-installation receipt and current native ownership. Setup intent only binds the reviewed local action and strategy; actual destination resolution requires its original successful native setup receipts. Missing or stale provenance blocks delivery. Parsing neither proves that setup ran nor authorizes a provider request. Accepted provider ingestion doesn't establish attribution or bidding success.
+
+### Google campaign configuration
+
+`parseResonanceGoogleConfigurationSaveCommand` reads a strict draft request
+with `schemaVersion: 1`, `expectedCampaignRevision`, `expectedRevision`,
+`idempotencyKey`, the required `signalSemantics`,
+`declaration: { statement, category }` and one top-level mode:
+
+- `existing`: `nativeGoal: { externalId, actionIds }`, using full native Google
+  resource names. The unique action set is sorted by the parser.
+- `admitted_setup`: `setupIntent: { requestedGoalName, requestedActionName }`.
+  These are intended display names, bounded to 160 characters, not purported
+  native resources. The server
+  derives the complete setup specification.
+
+Revision `0` expects no saved configuration. The server checks the campaign
+and configuration revisions and recovers the original operation by its key.
+Parsing doesn't save, approve or spend anything. Save the campaign and channel
+first, retain their IDs, then save their configuration. The configuration
+response supplies the resulting `campaignRevision`, configuration `revision`,
+`operationId` and `replayed`. Retry an uncertain save with its original key and
+body before starting another operation. Re-read the actual campaign after an
+uncertain initial draft save; its stable ID may now have a later revision.
+
+The required `signalSemantics` is `qualified_at_observation_v1` for both
+modes and the setup specification. It describes an explicitly reviewed
+**historical provider bid signal**, distinct from Sonor's unchanged
+`current_at_observation` qualified counts. It doesn't promise equal counts or
+provider count retraction. Existing and new setup profiles currently support
+only `qualified_lead` with `unique_qualified_contact` and a 1–90 day window.
+Actual producer eligibility, permanent contact/destination deduplication and
+delivery remain server checks. Other goal profiles are unsupported.
+
+The declaration's explicit statement is
+`DOES_NOT_CONTAIN_EU_POLITICAL_ADVERTISING`; its category is `general`,
+`housing`, `employment` or `financial_products_services`. The server binds it
+to actual source, account, creative, copy, destination and region scope, with
+the actual declarant UUID, timestamp and original
+`declaredForCampaignRevision`. No permanent statement is inferred from a brand
+or site. These fields aren't approval identities. The exact statement and
+resource effects are reviewed within the same campaign mandate.
+
+`parseResonanceGoogleConfigurationSnapshot` reads the canonical public snapshot
+with `configurationRevision` and `configurationDigest`. Its top-level mode
+remains explicit. Existing-mode native goal name and revision may be `null`
+when draft evidence is unavailable; a real empty provider label stays empty.
+`parseResonanceGoogleConfigurationReview` requires actual name and SHA-256
+revision for existing mode.
+
+Setup mode contains `setupSpec` and `setupDigest`, with no `nativeGoal` or
+purported native ID/revision. `ResonanceGoogleUploadClicksCustomGoalSpec` has
+one singular `action`, one matching `goalActionKey`, fixed local dependency
+keys, requested names and `exclusive_custom_goal_v1`. There are no
+`actions[]` or `goalActionKeys[]` aliases. The bounded first setup profile is
+`qualified_lead` with `unique_qualified_contact`, an `UPLOAD_CLICKS` action,
+`QUALIFIED_LEAD`, `ONE_PER_CLICK`, `primaryForGoal: false`, and the exact
+objective attribution window from 1 through 90 days. Other new setup pairs
+are unsupported; longer windows aren't clamped. Actual contact deduplication
+and delivery identity remain upstream responsibilities. Native per-click
+counting doesn't implement global contact deduplication. Canonical outcomes
+and provider reports remain separate.
+
+`projectResonanceGoogleConfiguration(snapshot, { ready, activationReadiness,
+reasonCodes })` is the one public view/review projection. The view renames
+`configurationRevision` to `revision` and adds fresh resolver metadata.
+`ready` means reviewable, not activated: planned setup uses `pending_setup`,
+unready configuration uses `blocked`, and existing setup requires final
+verification or verified native evidence. An unready view returns
+`review: null`. The corresponding view/save-response parsers validate these
+shapes without granting authority.
+
+`resonanceGoogleSetupDigestInput` and
+`resonanceGoogleConfigurationDigestInput` return canonical JSON for the server
+hash function. The configuration input omits only its self
+`configurationDigest`; initial content needs no placeholder. Private
+eligibility or authorization evidence doesn't belong in this public snapshot.
+`RESONANCE_GOOGLE_SOURCE_CATEGORIES` and `googleConversionActionSemantics`
+share native vocabulary with explicit counting and window inputs; vocabulary
+membership grants no broader setup eligibility.
+`googleUploadClicksSetupSemantics({ source, countingUnit, attributionWindowDays })`
+is the shared narrow policy check. It doesn't establish an actual source
+producer or delivery identity.
+
+Every prepared preview requires `googleConfiguration`: a strict existing or
+setup review for Google Search, explicit `null` for other channel kinds.
+Project, campaign, channel, site, account binding, source, measurement,
+counting, window and regions must match the enclosing plan. Preparing setup
+performs no provider mutation. After the same native mandate and admission,
+actual receipts resolve local keys to native IDs without rewriting the
+accepted public plan. Activation still needs current native eligibility,
+source, consent and authority checks. No parser proves those checks occurred.
+
+
+### Original Meta website-visit feed
+
+`ResonanceMandateScope` accepts an optional `websiteVisitFeed` with the profile `sonor_sdk_page_view_fresh_v1` and a `channels` list. Each entry selects an original Meta channel, a `measurementConfigRef`, `resourceRuleRefs` and a `matchingProfileRef`. Account, dataset and site come from that same channel in the reviewed plan. The matching-profile reference identifies the protected configuration-save receipt, its positive integer CAS revision and its digest. No feed is granted when the field is absent. A launch permission, measurement setting or visitor consent alone doesn't grant this feed.
+
+`RESONANCE_WEBSITE_VISIT_PROFILE` is the fixed, immutable local policy. `resonanceWebsiteVisitProfileDigestInput()` returns its canonical bytes for the server to hash. `resonanceMeasurementConfigDigestInput(config)` parses the measurement config and returns canonical semantic bytes, excluding only `expiresAt`. Current expiry still needs a separate check at capture and every dispatch. Renewal changes no original grant window; a semantic change at the same revision changes the digest. Both helpers retain approved list order and use the same canonical serializer as the existing mandate and command digests.
+
+The existing command union adds `deliver_website_visit` for the protected native operation path. It carries one original Meta channel and an internal `occurrenceId`, alongside the existing plan, review, revision, idempotency and mandate references. It carries no matching values, timestamps, dataset or provider body. `parseResonanceCommand(value, { preparedPlan, mandate, now })` checks original public grant consistency; it can't establish a protected producer, native claim or permission to send. Manual, public API and MCP entry points must reject attempts to originate this command. Native consumers must use the existing action ledger, standing approval and durable admission path.
+
+Measurement occurrences gain optional `pagePath` and `metaCookieObservation` fields on `page_view` only. The cookie observation has source `sdk_reported_first_party_cookie` and one or both actual reported `fbp`/`fbc` values. Each value is limited to 1–1024 characters with no whitespace or controls. Matching requires the path and existing resource reference on that same occurrence and navigation. The API must verify the owned site and exact approved rule/path/resource. A separate-origin API can't infer the site's first-party cookies from its own Cookie header. Raw matching belongs only in protected capture persistence, never ledger payloads, operation requests, results, receipts, public configuration or read responses.
+
+This is an SDK-reported observation. It doesn't prove that a person rendered a page or create a qualified lead or business conversion. The server-only event ID is the internal occurrence UUID; browser/server pairing is unsupported when the browser uses its different public event ID.
+
+`resonanceWebsiteVisitEventTime({ occurredAt, receivedAt }, { mandate, approvedAt, now })` checks the local time arithmetic and returns epoch seconds from the original reported `occurredAt`. The first receipt and final attempt must each be within 300,000 milliseconds of that original time, inclusive, with zero future allowance. Both original times must follow the original accepted feed approval and stay within its original window. It never substitutes receipt, retry or regrant time. This is Sonor's conservative policy, not a Meta age limit or acceptance guarantee. An authenticated exact-body replay must return its original stored identity and first receipt before new-capture age checks, without insertion, enrichment, queueing or resend. Current consent epochs, grant, kill, claim and global dedupe checks remain native owner responsibilities.
+
+These pure contracts don't install capture, a protected configuration writer, a matching-profile producer or native delivery. Those owners must implement and verify the actual preparation, original-delivery and terminal non-effect response boundaries before adoption. Parsing a valid payload doesn't make a provider ready or prove delivery.
+
+### Original Meta age selection
+
+An original Meta channel accepts optional `ageConstraint: { mode: 'bounded', min, max } | { mode: 'omitted' } | { mode: 'provider_managed' }`. The provider-managed intent has separate native observation requirements described below. Bounded values are integers from 1 to 120 with `min <= max`; these are local transport bounds, not country, category or provider policy. An absent field preserves legacy bytes and leaves new preparation unresolved. It doesn't select a default. Explicit omission or bounds require an actual current policy witness, and native readback must account for any source-backed normalization. Adapters must block unknown policy rather than ignore the selection or invent ages. This representation doesn't establish that a compiler, account or provider supports it.
+
+### Native measurement bootstrap and Meta configuration
+
+The pure setup contracts describe native owner inputs and saved projections. They don't create provider resources, grant visitor consent, approve spend, or enable the website-visit feed. Native API, SQL, preparation, approval and provider owners must adopt and verify them separately.
+
+`ResonanceMeasurementConfigurationSaveCommand` selects actual native pages using `{pageId, observedRevision, observedDigest}`. Its closed input also includes `schemaVersion: 1`, `site`, `expectedCampaignRevision`, `expectedConfigurationRevision`, `idempotencyKey`, `enabled` and the basic consent-purpose requirements. It accepts no caller path, rule ID, resource reference, expiry or readiness flag. The three advertising purpose requirements are mandatory; a requirement doesn't grant that purpose to a visitor.
+
+The native sequence starts with a managed draft and its owned sites; channels can be absent or empty. Measurement bootstrap uses that real draft as an operation audit home. It creates no complete advertising channel. After saving real page rules, the existing audience owner can create logical rules, and the campaign owner can save a complete Meta channel with those returned references. Meta configuration then maps those same logical rules to existing native audiences or admitted creation intent. A present channel still requires its complete original fields.
+
+Measurement configuration CAS is scoped to project/site. Zero expects actual absence; a legacy or malformed row without protected provenance must block. An audit campaign's revision check doesn't partition the site configuration or advance that campaign's review revision. `projectResonanceMeasurementConfiguration(command, context)` accepts an authorized project, protected current projection, reloaded safe page facts and a native transport expiry. It derives one rule per actual page UUID, sorted by page ID. The page resource revision is canonical UTC milliseconds; the rule revision is the existing full native evidence digest. This preserves distinctions between source updates within one millisecond. Native SQL must independently validate the facts and recompute CAS decisions under its locks.
+
+Native semantic `configRevision` and `policyRevision` are positive decimal strings. Identical semantics and a new cache expiry preserve them. Page evidence, selected rules or enabled-state changes advance the configuration revision; only consent-policy changes advance the policy revision. Initial provider destinations are `[]`; updates preserve explicitly configured destinations. The helper returns the configuration, friendly page projections and `configurationDigestInput` from the existing `resonanceMeasurementConfigDigestInput`. Hash that exact string once. The save-request digest helper retains original request array order, while derived semantic pages and purposes are sorted.
+
+Measurement `Current` distinguishes actual `unconfigured` revision zero from a saved `configured` projection with current reasons. `Snapshot` contains the original audit campaign, operation, configuration and friendly page evidence. `SaveResponse` adds `replayed`. The native owner must return an exact original same-key result before fresh CAS/source checks, while enforcing current read permission; a changed request conflicts. No parser proves native provenance.
+
+The agreed native freshness model is one read-only current-configuration resolver. It checks actual current ownership, protected saved provenance, native page evidence, configuration and policy, then issues a 300-second cache envelope from the database clock. All native purpose, consent, intake, audience, attribution and feed gates must use that same resolver. Reads must not mutate settings, create renewal operations or change original saved bytes. The cache envelope never extends consent, capability, mandate, feed, flight or kill authority. Source drift requires an explicit protected save. This is an adoption requirement, not a claim that those native ports are implemented by this package.
+
+`ResonanceMetaConfigurationSaveCommand` contains the expected campaign/configuration revisions, schema version, idempotency key and exact original logical audience mappings:
+
+```ts
+{ audienceRuleId, mode: 'existing', nativeAudienceRef: { externalId, revision } }
+// or
+{ audienceRuleId, mode: 'admitted_setup' }
+```
+
+The original channel remains the editable account, dataset, Page, Instagram, country, category, age, budget, creative and destination definition. Save accepts no duplicate channel, provider request, created audience ID for setup intent, matching data or approval flag. The existing native audience reference uses its actual numeric external ID and source evidence revision.
+
+`ResonanceMetaConfigurationSnapshot` freezes the original channel, root/configuration revisions, reviewed definition digest, saved operation UUID, advertiser and nullable native names, measurement/profile references, friendly rules and resolved audiences. Each audience row is `{audienceRuleRef, name, resourceRuleRef, excludedResourceRuleRefs, selection}`. Its logical name is separate from `selection.nativeAudienceName`; its positive rule is separate from exclusions. Existing selection carries the native reference/name. Admitted selection carries `setup: {kind: 'meta_website_audience_v1', localOutputKey, specDigest}`. The local key is the original SDK `audience:<id>:<revision>` key; `specDigest` identifies the existing SDK audience input. Native HTTP request and compiled graph identities remain distinct private preparation evidence.
+
+The matching-profile ID is the actual persisted save operation UUID. Its revision is the positive **integer** configuration CAS; measurement configuration/policy strings are different fields. Native save must atomically persist the real operation, settings and snapshot before exposing that reference. A new explicit Meta save advances its configuration CAS and campaign review revision; the snapshot carries the resulting root revision. A replay advances neither. Draft metadata receipts don't require fabricated prepared versions or operational channel rows.
+
+`resonanceMetaConfigurationDigestInput` omits only its self digest and preserves all original material, including friendly labels. `projectResonanceMetaConfiguration(snapshot, currentMetadata)` returns `{view, review}`. Metadata contains `currentCampaignRevision`, native-owner-derived `currentDefinitionDigest`, `observedAt`, nullable `expiresAt`, `reasonCodes` and `pendingRequirements`. `readyForReview` is derived output: no blockers, a current root revision at least as new as the saved audit revision, an exact match between the current semantic definition digest and the saved reviewed definition digest, and a nonexpired observation horizon. Metadata-only root revision bumps can therefore preserve multiple unchanged channel configurations; original snapshots keep their real save revisions. Native owners must still verify the exact original channel, configuration CAS, saved operation, configuration digest and current source/resource/account/policy facts. A matching campaign digest never substitutes for those checks. The review is the unchanged original snapshot when those prerequisites hold, otherwise `null`. Pending native creation, validation or age observation never grants execution. Pure timestamp ordering doesn't prove freshness when a cached view is consumed; the actual owner and UI must withdraw stale reviewability.
+
+### Explicit feed selection and original review
+
+`parseResonanceMandateDraftRequest` preserves the existing `{expectedRevision, allowedOperations, expiresAt}` request and accepts an optional minimal selection:
+
+```ts
+websiteVisitFeedSelection: {
+  channels: [{ channelId, expectedConfigurationRevision, resourceRuleRefs: [{ id, revision }] }]
+}
+```
+
+Absent selection preserves no-feed behavior. Empty lists, duplicate selectors, full editable grants and copied destination/profile/readiness fields are rejected. The native owner resolves the exact saved configuration, profile receipt and positive rule versions through the existing mandate authority. An excluded-only page can't become a selected feed permission.
+
+The existing mandate-draft response remains the raw `ResonanceMandateApprovalPayload`. Before acceptance, reviewers use that original payload with exact immutable configuration review snapshots; mismatched refs, digests, revisions or plan material block review. Latest labels must not replace original reviewed labels. Actual native approval can use the existing legitimate member or invited delegated-agent authority.
+
+`ResonanceWebsiteVisitFeedReview` is a separate **post-acceptance** projection: `{schemaVersion: 1, approval, mandateRef, configurations, current}`. It requires a genuine nonnull accepted mandate reference. Before acceptance, the native read returns its typed unavailable/not-found result. Original historical snapshots remain readable under current authorized scope when current state is invalidated or unavailable. `eligible` describes current review observation and grants no execution authority. No-feed requires `not_enabled` and an empty configuration list. The saved configuration audit revision can precede the exact original approval/plan revision, but can never follow it. The optional original prepared-plan context checks exact approval/plan revision, matching channel material and definition digest. Native original reads must supply the actual stored plan and verify the selected original configuration identities. Preparation, approval, claim and acceptance still require the exact current native root revision; this configuration review rule does not relax those fences. Actual approval provenance, hashes, source facts, consent and admission remain native checks.
+
+Native owners plan separate original configuration and accepted feed-review reads under the existing protected configuration/mandate owners. This package adds no endpoint, approval surface or provider client. Public, manual and MCP entry points must continue to reject internal `deliver_website_visit` before filing; a parser or service label never proves protected origin.
+
+### Provider-managed age intent
+
+The additional closed original Meta intent is `{mode: 'provider_managed'}`. It accepts no bounds, default flag or observed native values and never replaces absent, `omitted` or `bounded` intent. Its review promise is: “Use Meta age settings; record the initial observed configuration before activation.”
+
+Native create and validation requests must omit both age keys. Before activation, the first genuine same-root PAUSED AdSet creator receipt and complete scoped read must seal initial age values **and key presence** once in the existing protected operation. Activation must compare that unchanged observation and every independent non-age, consent, authority and budget gate. Later changes block. This intent makes no claim about exclusive default authorship, unlimited ages, legality or serving. Existing three-mode consumers need explicit preservation, editing and review support before adopting this branch.