Parser v1.1.1: examples and flexibility

For review. No decision recorded.

Prepared 6 October 2026.

A welcome offer can advertise two deposit bonuses and free spins on the same page. The useful result is a set of terms that preserves which deposit earns each benefit, which wagering rule applies, and which statement supports it. The examples below show how parser v1.1.1 is designed to retain those distinctions, read broader casino terms and accommodate changes to supported definitions.

This is proposed scope illustrated with fictional worked examples, not a shipped parser or integration. All casino names, sources and values in the examples are invented; origins use example.invalid. JSON keys, enums and nesting are illustrative review notation, not frozen API contracts. Reviewing this document does not select implementation or deployment.

Decision requested

Review whether the examples preserve the terms your team needs to inspect and use. Identify a field, relationship or outcome that should change, preferably with a source passage and the expected result. The review questions focus on the distinctions most likely to affect downstream catalogue work.

Read the examples

Start with this question	Worked example
Can cash and spins keep different rules across deposits?	Welcome offer
Can payment and account terms stay attached to their conditions?	Profile, banking and general terms
Can it describe money released in instalments?	No-deposit and repeated unlocks
What does a cashback percentage actually apply to?	Cashback
What if a page needs a browser, or staff already have the HTML?	Input modes and country context
Can a technical author add a nested field without an engine release?	Definition change
What happens after a retry or a failed delivery?	Retained result and delivery

The field inventory lists the full selected pack. The evidence boundary separates these examples from the small experiments already recorded and the acceptance work still required.

Welcome offer: two stages with separate cash and spins

Source passages

The fictional Lumen Casino welcome package has two deposit stages. Each row below is an exact retained excerpt in this example. Captures were taken at 2026-10-06T09:00:00Z in an International analysis for the illustrative target market Ireland, using a requested and observed Ireland route. The eligibility statement comes from the source; the route does not establish it.

Evidence	Source URL	Exact excerpt
W0	`https://lumen.example.invalid/welcome`	“Two-deposit welcome. New customers resident in Ireland, aged 18 or over. Use LUMEN. Claim within 7 days of registration.”
W1	`https://lumen.example.invalid/welcome`	“Deposit 1: deposit at least EUR 20 for a 100% cash bonus up to EUR 100. Wager deposit plus bonus 30 times within 14 days of cash-bonus credit. Maximum bet with this cash bonus: EUR 5. Maximum cashout from this cash bonus: EUR 1,000.”
W2	`https://lumen.example.invalid/welcome`	“Deposit 1 also awards 20 free spins on Lantern Reels at EUR 0.10 per spin. Wager free-spin winnings 40 times within 7 days of spin-winnings credit. Maximum bet while wagering those winnings: EUR 2. Maximum cashout from those winnings: EUR 50.”
W3	`https://lumen.example.invalid/welcome`	“Deposit 2: deposit at least EUR 30 for a 50% cash bonus up to EUR 75. This cash bonus has no wagering requirement. Maximum bet with this cash bonus: EUR 5.”
W4	`https://lumen.example.invalid/welcome-terms`	“For new customers resident in Ireland, maximum cashout from the deposit 1 cash bonus in Two-deposit welcome is EUR 1,500.”

Expected structured result

The projection uses a component's evidenceIds for its displayed terms; offer terms use W0. A term with competing support is shown separately in conflicts. IDs identify the example's structure and are not text claimed to appear on the page. Monetary amounts are exact decimal strings with explicit currency; a wagering multiplier always names its base.

{
  "offerId": "welcome",
  "type": "welcome",
  "headline": "Two-deposit welcome",
  "audience": { "residence": "Ireland", "customerStatus": "new", "minimumAge": 18 },
  "code": "LUMEN",
  "claimWindow": { "value": 7, "unit": "day", "startsAt": "registration" },
  "evidenceIds": ["W0"],
  "stages": [
    {
      "stageId": "deposit-one",
      "depositNumber": 1,
      "components": [
        {
          "componentId": "first-cash",
          "kind": "cash_bonus",
          "minimumDeposit": { "amount": "20", "currency": "EUR" },
          "matchPercentage": "100",
          "maximumBonus": { "amount": "100", "currency": "EUR" },
          "wagering": { "state": "required", "multiplier": "30", "base": "deposit_plus_bonus" },
          "wageringWindow": { "value": 14, "unit": "day", "startsAt": "cash_bonus_credit" },
          "maximumBet": { "amount": "5", "currency": "EUR" },
          "evidenceIds": ["W1"]
        },
        {
          "componentId": "first-spins",
          "kind": "free_spins",
          "count": 20,
          "spinValue": { "amount": "0.10", "currency": "EUR" },
          "gameRestrictions": ["Lantern Reels"],
          "wagering": { "state": "required", "multiplier": "40", "base": "free_spin_winnings" },
          "wageringWindow": { "value": 7, "unit": "day", "startsAt": "spin_winnings_credit" },
          "maximumBet": { "amount": "2", "currency": "EUR" },
          "maximumCashout": { "amount": "50", "currency": "EUR" },
          "evidenceIds": ["W2"]
        }
      ]
    },
    {
      "stageId": "deposit-two",
      "depositNumber": 2,
      "components": [
        {
          "componentId": "second-cash",
          "kind": "cash_bonus",
          "minimumDeposit": { "amount": "30", "currency": "EUR" },
          "matchPercentage": "50",
          "maximumBonus": { "amount": "75", "currency": "EUR" },
          "wagering": { "state": "none" },
          "maximumBet": { "amount": "5", "currency": "EUR" },
          "evidenceIds": ["W3"]
        }
      ]
    }
  ],
  "conflicts": [
    {
      "offerId": "welcome",
      "stageId": "deposit-one",
      "componentId": "first-cash",
      "field": "maximumCashout",
      "applicability": { "residence": "Ireland", "customerStatus": "new" },
      "state": "conflict",
      "resolvedValue": null,
      "alternatives": [
        { "value": { "amount": "1000", "currency": "EUR" }, "evidenceId": "W1" },
        { "value": { "amount": "1500", "currency": "EUR" }, "evidenceId": "W4" }
      ]
    }
  ]
}

W1 and W4 describe the same cashout term for the same stage, component and audience. Both alternatives survive; the terms page does not automatically win. The EUR 50 spin cashout is a different component's limit, so it is not a third alternative in that conflict.

A reviewer can trace the 40-times rule directly to the spins instead of accepting a single package-wide wagering number. The EUR 100 bonus award ceiling, EUR 50 spin cashout ceiling and ordinary cashier withdrawal limit below answer different questions. Missing deposit-two spins or cashout information remains unstated; it does not create zero spins or unlimited cashout. Likewise, the explicit no-wagering statement on deposit two cannot fill a missing condition elsewhere.

Profile, banking and general terms

A profile and two payment directions

The next three passages share the welcome example's capture time and analysis context. They are fictional operator statements, including the fictional licence authority and status.

Evidence	Source URL	Exact excerpt
P1	`https://lumen.example.invalid/about`	“Lumen Casino opened in 2020. Operated by Lumen Leisure Ltd on the Orbit platform. Website languages: English and French. Live chat is available; email support@lumen.example.invalid. Game suppliers include Lantern Studio.”
P2	`https://lumen.example.invalid/legal`	“Lumen Leisure Ltd states that it holds an active Example Gaming Authority licence EX-204 in Example Jurisdiction. Verification link: https://lumen.example.invalid/licence. Customer funds are held separately from operating funds.”
B1	`https://lumen.example.invalid/payments`	“ClearPay in EUR: minimum deposit EUR 15. Minimum withdrawal EUR 25; maximum withdrawal EUR 2,000 per calendar day. Withdrawal fee EUR 2; processing takes 1 to 3 business days after approval. Withdrawals must use the deposit method.”

This projection retains publisher attribution and keeps each payment direction in its own row. B1 supports both rows, but the fee, processing window and maximum belong only to withdrawals.

{
  "profile": {
    "displayName": "Lumen Casino",
    "officialUrl": "https://lumen.example.invalid/",
    "establishmentYear": { "value": 2020, "subject": "casino", "evidenceId": "P1" },
    "operatorLabel": { "value": "Lumen Leisure Ltd", "evidenceIds": ["P1", "P2"] },
    "platformLabels": { "values": ["Orbit"], "evidenceId": "P1" },
    "websiteLanguages": { "values": ["English", "French"], "evidenceId": "P1" },
    "support": { "liveChatStated": true, "email": "support@lumen.example.invalid", "evidenceId": "P1" },
    "gameStudioLabels": { "values": ["Lantern Studio"], "evidenceId": "P1" },
    "licenceStatement": {
      "assertedHolder": "Lumen Leisure Ltd",
      "authority": "Example Gaming Authority",
      "jurisdiction": "Example Jurisdiction",
      "number": "EX-204",
      "statedStatus": "active",
      "verificationLink": "https://lumen.example.invalid/licence",
      "evidenceId": "P2"
    },
    "fundsProtectionStatement": { "value": "Customer funds are held separately from operating funds.", "evidenceId": "P2" }
  },
  "paymentPolicies": [
    {
      "methodLabel": "ClearPay", "direction": "deposit", "currency": "EUR",
      "minimum": { "amount": "15", "currency": "EUR" }, "evidenceId": "B1"
    },
    {
      "methodLabel": "ClearPay", "direction": "withdrawal", "currency": "EUR",
      "minimum": { "amount": "25", "currency": "EUR" },
      "maximum": { "amount": "2000", "currency": "EUR", "period": "calendar_day" },
      "fee": { "amount": "2", "currency": "EUR" },
      "processingWindow": { "minimum": 1, "maximum": 3, "unit": "business_day", "startsAt": "approval" },
      "methodMatching": "deposit_method", "evidenceId": "B1"
    }
  ]
}

The official URL is retained source identity, not an independently verified catalogue identity. A redirect would be a domain candidate for review, not an automatic Casino rename. The licence and funds-protection passages remain claims made by the publisher; extraction does not check a registry or prove protection. A listed studio does not establish a complete game catalogue, and absence of a chat widget would not establish that chat is unavailable.

For catalogue use, ClearPay/EUR/withdrawal stays one correlated policy. The parser does not invent ClearPay support for another currency, infer a withdrawal capability from a deposit-only logo, or confuse three business days of processing with a daily cash limit.

All 16 general-terms definitions

The table completes the general-terms example. Rows G1 to G11 are separate retained passages from https://lumen.example.invalid/general-terms, captured in the same context. B1 and P2 refer to the exact passages above. Each expected result retains its row's evidence and stated condition.

Definition	Evidence and exact source excerpt	Expected structured meaning
Withdrawal fee	B1: “Withdrawal fee EUR 2”	ClearPay / withdrawal / EUR: fee amount `"2"`, currency `EUR`.
Instalment schedule	G1: “Approved withdrawals over EUR 2,000 are paid in instalments of up to EUR 2,000 per calendar day.”	Threshold `2000 EUR`; instalment ceiling `2000 EUR`; period `calendar_day`; applies to approved withdrawals over threshold.
Method matching	B1: “Withdrawals must use the deposit method.”	Withdrawal condition: use the deposit method.
Processing window	B1: “processing takes 1 to 3 business days after approval.”	Minimum 1, maximum 3, unit `business_day`, start `approval`.
Deposit playthrough	G2: “Deposited funds must be wagered once before withdrawal.”	Multiplier `"1"`, base `deposit`, prerequisite for withdrawal.
Inactivity trigger	G3: “An account becomes inactive after 12 months without a login.”	Trigger: no login.
Inactivity period	G3: “An account becomes inactive after 12 months without a login.”	Duration: 12 months since the last login.
Inactivity charge	G4: “Inactive accounts are charged EUR 5 per month while a positive balance remains.”	`5 EUR` per month; condition: inactive account with positive balance.
Funds protection	P2: “Customer funds are held separately from operating funds.”	Attributed statement, with independent verification unstated.
Account closure	G5: “Customers may request account closure by contacting support.”	Source-stated closure condition: customer request through support.
Balance confiscation	G6: “Balances may be confiscated if forged identity documents are supplied.”	Conditional publisher statement; condition retained, no finding about a player.
Complaints process	G7: “Send complaints to complaints@lumen.example.invalid with your account reference.”	Email channel, address and requested account reference.
Dispute-resolution body	G8: “Unresolved complaints may be referred to Example Dispute Panel.”	Named body and condition: unresolved complaint.
Governing law	G9: “The agreement is governed by the law of Example Jurisdiction.”	Attributed governing-law label: Example Jurisdiction.
Dispute deadline	G10: “Refer a dispute within 30 days of our final complaint response.”	Duration: 30 days; start: final complaint response.
Withdrawal affecting bonus	G11: “Withdrawing while a Lumen cash bonus is active forfeits that cash bonus.”	Active Lumen cash bonus; withdrawal triggers forfeiture.

These terms let an editor distinguish a withdrawal fee from a confiscation condition, or an inactivity trigger from its charge. They remain attributed statements, not legal assessments or player-impact scores. The general deposit playthrough rule and deposit two's bonus-specific no-wagering statement have different bases; neither silently replaces the other.

No-deposit and repeated unlocks

A no-deposit award with a withdrawal condition

N1 is a fictional retained passage from https://lumen.example.invalid/no-deposit, using the same capture context:

New customers resident in Ireland aged 18 or over: claim EUR 10 without a deposit using TRY10. Wager the EUR 10 bonus 40 times. Maximum winnings withdrawable from this offer: EUR 50. A EUR 10 deposit is required before withdrawing those winnings.

{
  "offerId": "try-credit",
  "type": "no_deposit",
  "audience": { "residence": "Ireland", "customerStatus": "new", "minimumAge": 18 },
  "code": "TRY10",
  "noDepositAmount": { "amount": "10", "currency": "EUR" },
  "noDepositMaximumWinnings": { "amount": "50", "currency": "EUR" },
  "wagering": { "multiplier": "40", "base": "bonus" },
  "withdrawalRequirement": { "minimumDeposit": { "amount": "10", "currency": "EUR" } },
  "evidenceId": "N1"
}

The offer can be claimed without a deposit while withdrawal still requires one. Keeping the trigger and withdrawal requirement separate prevents a catalogue from describing the entire offer as unconditionally deposit-free. The EUR 50 limit is this offer's maximum winnings, not the cashier's daily withdrawal limit.

Four releases, with package totals preserved

U1 is a fictional retained passage from https://lumen.example.invalid/unlock, in the same context:

Ireland residents aged 18 or over: deposit EUR 25 to join Four-step release. Unlock four EUR 10 increments, a package total of EUR 40. For each increment, wager 10 times the original qualifying deposit. Full unlock requires 40 times that deposit, stated here as EUR 1,000 of wagering. Each unlocked increment may be used on slots only. Withdraw unlocked funds only after all four increments are unlocked.

{
  "offerId": "four-step-release",
  "type": "incremental_unlock",
  "audience": { "residence": "Ireland", "minimumAge": 18 },
  "stages": [
    {
      "stageId": "qualifying-deposit",
      "qualifyingDeposit": { "amount": "25", "currency": "EUR" },
      "unlock": {
        "unlockCount": 4,
        "increments": [
          { "incrementId": "release-one", "order": 1, "value": { "amount": "10", "currency": "EUR" }, "wagering": { "multiplier": "10", "base": "original_qualifying_deposit" }, "evidenceId": "U1" },
          { "incrementId": "release-two", "order": 2, "value": { "amount": "10", "currency": "EUR" }, "wagering": { "multiplier": "10", "base": "original_qualifying_deposit" }, "evidenceId": "U1" },
          { "incrementId": "release-three", "order": 3, "value": { "amount": "10", "currency": "EUR" }, "wagering": { "multiplier": "10", "base": "original_qualifying_deposit" }, "evidenceId": "U1" },
          { "incrementId": "release-four", "order": 4, "value": { "amount": "10", "currency": "EUR" }, "wagering": { "multiplier": "10", "base": "original_qualifying_deposit" }, "evidenceId": "U1" }
        ],
        "statedPackageValue": { "amount": "40", "currency": "EUR" },
        "fullUnlockWagering": { "multiplier": "40", "base": "original_qualifying_deposit", "statedAmount": { "amount": "1000", "currency": "EUR" } },
        "permittedUse": "slots_only",
        "withdrawalRequirement": "all_four_increments_unlocked"
      },
      "evidenceId": "U1"
    }
  ],
  "evidenceId": "U1"
}

Four increments remain four owned items. Each EUR 10 release and its 10-times requirement retains the original deposit as its base; it is not 10 times the release value or a 40-times requirement on each increment. Both package totals are explicitly stated in U1. The parser preserves them without calculating a player's progress or introducing a general promotion calculator. Repeated structures also allow different source-stated amounts or conditions on different increments without flattening the schedule into one number.

Cashback with its calculation base

C1 is a fictional retained passage from https://lumen.example.invalid/cashback, in the same context:

Ireland residents aged 18 or over with a verified account and no active bonus receive 10% cashback on net cash losses on slots, excluding bonus-funded play. The calculation period is Monday 00:00 through the following Monday 00:00 UTC, with the end excluded. Maximum cashback is EUR 50 per period. At least EUR 100 in net cash losses in that period is required.

{
  "offerId": "weekly-slots-cashback",
  "type": "cashback",
  "audience": { "residence": "Ireland", "minimumAge": 18 },
  "percentage": "10",
  "calculationBase": { "measure": "net_cash_losses", "games": "slots", "excludes": ["bonus_funded_play"] },
  "period": { "unit": "week", "startsAt": "Monday 00:00", "endsAt": "following Monday 00:00", "endExclusive": true, "timezone": "UTC" },
  "cap": { "amount": "50", "currency": "EUR", "appliesPer": "calculation_period" },
  "qualifications": {
    "verifiedAccountRequired": true,
    "activeBonusAllowed": false,
    "minimumNetCashLosses": { "amount": "100", "currency": "EUR", "appliesPer": "calculation_period" }
  },
  "evidenceId": "C1"
}

“10% cashback” alone hides who qualifies and which losses count. This result keeps the exclusions, period and cap together so an editor can describe the published proposition. It contains no player balance, loss history or calculated reward. An unfamiliar promotion that cannot be represented by an admitted definition remains a bounded observation with its source, exact excerpt and proposed description, separate from typed claims.

Two input modes and country context

Reading an official URL

An authorized client supplies an official URL. The service first reads the page through the configured regional route using ordinary HTTP. When capture signals show required text is missing because the page renders it dynamically, the service may use a browser in the same country. Shared, bounded reading actions can open public terms, switch a content tab or reveal text. Already retained text needs no click.

There is at most one logical HTTP-to-browser escalation per page, country and run. Bounded transient retries are separate; recovery does not reset that allowance. A missing model field or an HTTP success code alone is not a reason to escalate or a proof that the required text was captured. An unsupported action or unavailable regional route produces a coverage gap. The service does not silently switch to direct access or a different country.

The service can follow admitted official help or terms sources on another host when their publisher association is established. A link alone is insufficient. It uses shared reading behavior rather than customer-authored bonus scripts for each site. Accounts, PDF processing and arbitrary autonomous browsing are outside this HTML workflow.

A targeted run does not mean universal eligibility

Suppose an illustrative configuration permits Ireland and Finland. A client explicitly requests only Ireland and supplies the following input context. These country choices explain the example; they are not a launch-country list or an access guarantee.

{
  "analysisApproach": "International",
  "targetMarket": "Ireland",
  "sourceMode": "url",
  "scope": { "kind": "targeted", "countries": ["Ireland"], "expandCountries": false },
  "requestedRoute": "Ireland"
}

Expected observations stay separate:

Observation	Structured result and consequence
Welcome page retrieved through the requested route	`observedRoute: Ireland`, with retained route/access evidence and its verification limits. This is an access observation.
W0 says “New customers resident in Ireland, aged 18 or over”	Eligibility bound to the welcome offer, supported by W0. Neither page language nor route supplied this claim.
Selected Ireland payments page fails to load	Coverage gap for that selected source; no invented empty banking policy.
A Finland source candidate is encountered	Candidate retained as unvisited/outside scope; no additional Finland visit in this targeted run.

An ordinary URL run instead inherits the parser's configured required-country list and may visit discovered additional candidates within configured limits and available routes. Excess or unsupported candidates remain unverified. Neither kind of run changes shared defaults, creates a catalogue Market or proves eligibility across the casino. Accepted runs pin their effective settings even if defaults later change.

International describes the analysis approach; target market describes intended analysis context. Requested and observed routes describe retrieval. Source-stated eligibility describes the claim's applicability. A declared mixture of International and legislated-local analysis is rejected; local legal analysis is not supplied by choosing a country route.

Supplied HTML creates its own result

If staff already hold a public terms fragment, an authorized client can submit it directly. For example, staff submit one item attributed to https://lumen.example.invalid/welcome, class bonus_terms, captured at 2026-10-06T09:00:00Z, with International analysis, target market Ireland and staff-reported Ireland route. The entire fragment is:

<h2>Two-deposit welcome</h2>
<p>Deposit 1 also awards 20 free spins on Lantern Reels at EUR 0.10 per spin. Wager free-spin winnings 40 times within 7 days of spin-winnings credit. Maximum bet while wagering those winnings: EUR 2. Maximum cashout from those winnings: EUR 50.</p>

The expected result admits the W2 spin terms above using a new supplied-source evidence binding, UPL1. It does not borrow W0 or W1 to fill audience or cash terms absent from the fragment.

{
  "runId": "supplied-run",
  "sourceMode": "supplied_html",
  "provenance": "staff_upload",
  "failedRunReference": "earlier-failed-run",
  "context": { "analysisApproach": "International", "targetMarket": "Ireland", "reportedRoute": "Ireland", "observedServiceRoute": null },
  "evidenceId": "UPL1",
  "sourceUrl": "https://lumen.example.invalid/welcome",
  "pageClass": "bonus_terms",
  "capturedAt": "2026-10-06T09:00:00Z",
  "offer": { "offerId": "fragment-welcome", "headline": "Two-deposit welcome" },
  "component": {
    "offerId": "fragment-welcome",
    "stage": { "stageId": "fragment-deposit-one", "depositNumber": 1 },
    "componentId": "fragment-spins",
    "kind": "free_spins", "count": 20,
    "spinValue": { "amount": "0.10", "currency": "EUR" },
    "gameRestrictions": ["Lantern Reels"],
    "wagering": { "multiplier": "40", "base": "free_spin_winnings" },
    "wageringWindow": { "value": 7, "unit": "day", "startsAt": "spin_winnings_credit" },
    "maximumBet": { "amount": "2", "currency": "EUR" },
    "maximumCashout": { "amount": "50", "currency": "EUR" },
    "evidenceId": "UPL1"
  },
  "coverageGaps": ["offer_audience_not_in_supplied_content", "cash_terms_not_in_supplied_content"]
}

The service retains an immutable digest of the supplied content with this provenance; the projection omits the digest value. One to four HTML documents or fragments are allowed, totalling at most 4 MiB of HTML, with a separate request-envelope limit. Each item supplies its source URL, class, capture time and analysis/market/reported-route context.

This is a new immutable run. The earlier failed-run reference is traceability only: it imports no captures, merges no results and neither reopens nor changes that failed run. The service does not fetch linked pages, discover new sources or execute the supplied HTML in a browser. Missing material remains a gap. Staff-reported route and a declared official URL are attribution, not service-observed retrieval or proof of eligibility. The input API is separate from an upload UI and from definition preview; this explicit run produces a normal retained result and terminal notification.

Change a definition without rebuilding the engine

The following cases separate reusable structure from the source knowledge an author must supply. Each is a controlled definition exercise within the selected field pack; none removes a field from the complete delivered pack.

Change to inspect	Concrete case
Add a supported conditional object	Inactivity charge
Reuse an array with different values and evidence	Unequal releases
Check one nested scope without borrowing another's value	Bounded condition
Read another operator's wording into familiar fields	Shared field shape
Preserve combinations of method, direction and currency	Payment rows
Detect a plausible-looking but incorrect change	Preview comparison

From a deposit field to a repeated unlock schedule

A technical author should be able to express the Four-step release structure using supported strings, numbers, objects and arrays. The controlled exercise below starts with an intentionally earlier definition fixture, A, within parser v1.1.1. A knows the offer and qualifying deposit but omits the unlock object. Definition B adds that selected field and its repeated increments. This is an extension exercise: the delivered field pack includes unlock terms and maximum bet throughout.

Definition A: controlled starting point	Definition B: added supported composition
`offers[] → stages[] → qualifyingDeposit`	Same offer and stage identities, plus `offers[] → stages[] → unlock → increments[]`
Retained U1 contains terms A cannot represent	Each increment retains its order, money value, wagering base and U1 binding
No unlock values admitted under A	Preview expects all four supported releases, package totals, use and withdrawal condition shown in the unlock example

A compact schema fragment illustrates the nested addition. It is a review sketch, not the final definition syntax or complete evidence envelope; the executable definition must also constrain shared money, wagering, identity and support shapes.

{
  "type": "object",
  "properties": {
    "unlock": {
      "type": "object",
      "properties": {
        "unlockCount": { "type": "integer" },
        "increments": {
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "incrementId": { "type": "string" },
              "order": { "type": "integer" },
              "value": {
                "type": "object",
                "properties": { "amount": { "type": "string" }, "currency": { "type": "string" } }
              },
              "wagering": {
                "type": "object",
                "properties": { "multiplier": { "type": "string" }, "base": { "type": "string" } }
              },
              "evidenceId": { "type": "string" }
            }
          }
        }
      }
    }
  }
}

B also changes the extraction instructions: “Keep each stated release separate; bind its value and wagering base to that release and its exact supporting passage. Preserve stated package totals separately.” A bounded condition can inspect the nested items, for example whether a stage has an increment whose wagering base is original_qualifying_deposit. The admitted operation set and resource bounds constrain what authors can express.

Four responsibilities make that change useful:

Responsibility	What it contributes in this example
Instructions	Tell extraction which source meaning to look for, including per-increment versus package terms.
Schema	Describe the nested shape and reject wrong types, such as text in an integer count. Ajv supplies the shape checks.
Conditions	Apply admitted rules to candidate context and repeated items. JSON Logic supplies bounded condition evaluation.
Shared mapping and source admission	Preserve identities, exact units and bindings through storage and delivery; reject a structurally valid release unsupported by U1.

A new field name or composition of supported shapes can therefore avoid an engine deployment. It still needs authored instructions and human-checked source cases. A new normalization operation, unsupported evidence relationship or retrieval capability can require code. There is no arbitrary JavaScript, unrestricted workflow or custom text rule language hidden in a definition. A generic parser result also does not create a field, relationship or display in a consumer automatically.

Add an inactivity charge using existing value shapes

A controlled starting definition already extracts G3's inactivity trigger and 12-month period, but omits the charge. The retained source also contains G4: “Inactive accounts are charged EUR 5 per month while a positive balance remains.” Add an inactivityCharge object using the existing money, period and condition shapes. The instruction names the charge, its recurrence and its qualifying balance condition; it does not treat every inactive account as charged.

Expected addition to Lumen's profile:

{
  "inactivityCharge": {
    "amount": { "amount": "5", "currency": "EUR" },
    "recurrence": { "value": 1, "unit": "month" },
    "conditions": { "accountStatus": "inactive", "positiveBalanceRequired": true },
    "evidenceId": "G4"
  }
}

Schema validation checks the object and its supported child types. Shared mapping keeps G4 attached to the charge, while G3 remains attached to the trigger and period; no new retrieval action or casino-specific mapper is needed. The human-checked case must reject a result that changes the charge to EUR 5 per year or drops the positive-balance condition. If G4 is absent from retained content, preview reports missing support instead of borrowing another casino's fee.

Reuse the unlock shape for unequal releases

A second fictional operator, Sora Casino, describes a three-release offer. These new examples use synthetic retained captures at 2026-10-06T10:00:00Z, with International analysis, target market Ireland and illustrative requested/observed Ireland routes. Those context values do not supply eligibility claims. R1 to R4 come from https://sora.example.invalid/releases:

Evidence	Exact excerpt
R1	“Three-release offer: deposit EUR 25. There are three releases. Released funds may be used on slots only and withdrawn after all three releases.”
R2	“First release: EUR 5 after wagering 5 times the original qualifying deposit.”
R3	“Second release: EUR 10 after wagering a further 10 times the original qualifying deposit.”
R4	“Third release: EUR 15 after wagering a further 15 times the original qualifying deposit.”

Reuse the unlock object and repeated-item schema. Change the instruction to retain each stated amount, additional wagering step and exact passage independently; it must not assume every release equals the first. Shared mapping preserves the new offer, stage and increment identities.

{
  "offerId": "sora-three-release",
  "stageId": "sora-qualifying-deposit",
  "qualifyingDeposit": { "amount": "25", "currency": "EUR", "evidenceId": "R1" },
  "unlock": {
    "unlockCount": 3,
    "increments": [
      { "incrementId": "sora-release-one", "order": 1, "value": { "amount": "5", "currency": "EUR" }, "wagering": { "multiplier": "5", "base": "original_qualifying_deposit" }, "evidenceId": "R2" },
      { "incrementId": "sora-release-two", "order": 2, "value": { "amount": "10", "currency": "EUR" }, "wagering": { "multiplier": "10", "base": "original_qualifying_deposit" }, "evidenceId": "R3" },
      { "incrementId": "sora-release-three", "order": 3, "value": { "amount": "15", "currency": "EUR" }, "wagering": { "multiplier": "15", "base": "original_qualifying_deposit" }, "evidenceId": "R4" }
    ],
    "permittedUse": "slots_only",
    "withdrawalRequirement": "all_three_increments_unlocked",
    "evidenceId": "R1"
  },
  "unresolved": ["stated_package_value_not_found", "full_unlock_wagering_not_stated"]
}

Here wagering on an increment is the work for that increment, not a cumulative threshold. The expected result preserves EUR 5, EUR 10 and EUR 15 with R2, R3 and R4 respectively. It does not copy Lumen's four identical releases, U1 evidence or package totals, and it does not calculate an unstated total. If a source instead describes cumulative thresholds, the definition must preserve that distinction through admitted shapes and checks; silently treating them as additional steps would fail acceptance.

Keep a condition inside its selected stage

Suppose an admitted definition needs to ask whether the stage currently being checked contains any increment wagered on the original qualifying deposit. The application supplies that one stage as the condition's context. A JSON Logic expression can inspect its nested increments:

{
  "some": [
    { "var": "unlock.increments" },
    { "===": [{ "var": "wagering.base" }, "original_qualifying_deposit"] }
  ]
}

This uses the some, var and strict-equality operations exercised by the recorded library check. Inside some, the lookup refers to the current increment. The expression is an illustrative bounded condition, not a complete executable definition contract or permission to use every library operation.

Human-checked candidate context	Expected condition result	Why
Selected stage is Lumen's qualifying-deposit stage; its increments use the original qualifying deposit	`true`	At least one of this stage's increment bases matches.
Selected stage has one increment with `wagering.base: bonus`	`false`	The increment uses a different base.
Selected stage's increments all use `bonus`, but its package-level `fullUnlockWagering.base` says `original_qualifying_deposit`	`false`	The package field cannot stand in for an increment's field.
Selected stage's increments all use `bonus`; a different stage has a deposit-based increment	`false`	The other stage is outside the supplied condition context.

The instruction and schema still describe what is extracted; this condition only classifies the candidate supplied to it. Shared mapping must preserve the stage and item boundaries so the condition sees the intended object. A condition returning true neither proves source support nor accepts an entire offer. Mandatory source/entity checks can still reject a value or binding.

Read different wording into the same field shape

Lumen's W1 says “Maximum bet with this cash bonus: EUR 5.” In a separate Sora welcome offer, S1 at https://sora.example.invalid/welcome says “Sora welcome cash bonus: highest permitted stake while wagering this cash bonus is EUR 4.” S1 uses the synthetic capture context above. The phrase changes; the supported money field does not.

Source input	Expected field projection	Definition work and reuse
W1, Lumen's first cash component	`maximumBet: { amount: "5", currency: "EUR" }`, bound to `welcome / deposit-one / first-cash`, evidence W1	Existing instruction and money schema.
S1, Sora's welcome cash component	`maximumBet: { amount: "4", currency: "EUR" }`, bound to `sora-welcome / sora-cash`, evidence S1	Clarify that “highest permitted stake” expresses maximum bet; reuse the field shape, currency handling and scoped mapping. Do not import Lumen's stage count or terms.
S1D, a separate controlled capture variant at the same URL: “Sora welcome cash bonus: highest permitted stake while wagering this cash bonus is $4.” No currency clarification is retained.	Unresolved maximum-bet currency; retain the exact `$4` excerpt as a candidate with S1D evidence. No admitted EUR or USD money value.	Reuse the ambiguity rule. The target market and another capture's EUR wording do not supply the missing currency.

The dollar-symbol variant is a separate fixture, not competing evidence within the EUR example. Its acceptance case must remain unresolved. Supported normalization may turn explicitly stated EUR 4 into the shared exact-money shape; a new unsupported currency notation or conversion operation would need an agreed capability and potentially code. An instruction change cannot silently introduce that operation or establish Sora's catalogue identity. This lets a second source use the same field without making the first source's facts reusable.

Preserve conditional payment rows

S2 is a fictional passage at https://sora.example.invalid/payments, in the same synthetic context:

ClearPay deposits in EUR require at least EUR 10. ClearPay withdrawals in EUR require at least EUR 30 and take 2 business days after approval. RiverTransfer withdrawals in GBP require at least GBP 40 and take 4 business days after approval.

The instruction asks for one row per stated method, direction and currency, with timing attached to that row. Reuse the payment-policy shape; do not collect three independent lists of methods, directions and currencies.

{
  "sourceProfile": "sora",
  "paymentPolicies": [
    { "methodLabel": "ClearPay", "direction": "deposit", "currency": "EUR", "minimum": { "amount": "10", "currency": "EUR" }, "evidenceId": "S2" },
    { "methodLabel": "ClearPay", "direction": "withdrawal", "currency": "EUR", "minimum": { "amount": "30", "currency": "EUR" }, "processingWindow": { "minimum": 2, "maximum": 2, "unit": "business_day", "startsAt": "approval" }, "evidenceId": "S2" },
    { "methodLabel": "RiverTransfer", "direction": "withdrawal", "currency": "GBP", "minimum": { "amount": "40", "currency": "GBP" }, "processingWindow": { "minimum": 4, "maximum": 4, "unit": "business_day", "startsAt": "approval" }, "evidenceId": "S2" }
  ]
}

sourceProfile: sora is a local source-grouping identifier, not a resolved catalogue identity. No new field capability or retrieval script is required for these three rows. The shared schema supports repeated policy objects; mapping and source admission keep each object's attributes together. Acceptance rejects an invented ClearPay/GBP withdrawal, RiverTransfer deposit or a two-day time attached to ClearPay deposits. Missing combinations remain unsupported rather than unavailable. A new interaction needed to reveal the payment table would be a separate retrieval capability question, not something these extraction instructions implement.

Catch a semantic regression in preview

Use retained W0 to W4, G3 and G4 as one controlled reference case. Its earlier definition fixture already handles the welcome cash/spin terms and inactivity trigger/period, and omits only inactivityCharge. The candidate adds that object as above. A preview comparison must inspect existing bindings as well as the newly populated field:

Reference item	Previous result	Faulty candidate preview	Corrected expected preview
Inactivity charge	Field not represented by the fixture	EUR 5/month, positive-balance condition, G4	Same supported addition, bound to Lumen's profile and G4.
First cash wagering	30 times deposit plus bonus, W1	Same value, but evidence swapped to W2	Preserve 30 times deposit plus bonus with W1.
First spin wagering	40 times spin winnings, W2	Same value, but evidence swapped to W1	Preserve 40 times spin winnings with W2.
First cashout conflict	EUR 1,000 from W1 and EUR 1,500 from W4; resolved value unset	Silently chooses EUR 1,000	Preserve both alternatives, bindings and the unset resolved value.
Deposit-two cashout	Unstated in retained content	EUR 1,000 inherited from deposit one	Remain unresolved; no deposit-two cashout support was added.

The faulty preview can pass basic shape checks while failing source/entity admission and the mandatory human-checked expected bindings. Activation stays blocked even though the new inactivity field is correct. Correcting the extraction instructions or shared mapping issue is followed by another retained-content preview; the reference expectations are not rewritten to bless the regression. This example specifies the required outcome, not an observed model failure.

The corrected comparison must also preserve existing conflicts and explain any coverage change. It creates no production result or webhook. Only a passing mandatory gate permits activation for future explicit runs; accepted runs keep their pinned definition and historical result.

Preview, compare, then activate for future runs

Preview reuses retained content and may call the model for new extraction instructions. Its comparison checks that all four amounts still refer to their own increments and U1, that existing fields retain their meaning, and that conflicts and coverage are visible. A matching JSON shape or quotation alone does not establish correct source support.

Human-checked expected values, units, relationships and unresolved outcomes form the mandatory reference cases. Their failures block activation; the model cannot rewrite its own answer key. If retained material is insufficient, preview reports that gap without a hidden fetch. A preview is retained separately and creates neither a production result nor a webhook.

Activation changes the definition selected by future explicit runs. It does not queue every casino, alter existing accepted runs or rewrite historical results. A new run can then demonstrate B through the normal result read and webhook. This management flow uses the API; a definition editor or preview screen is not included.

One retained result through recovery and delivery

Consider a client that submits the welcome URL with one idempotency key, loses the acceptance response, then retries. Equivalent normalized content and context with that key resolve to one accepted run, including concurrent retries. Reusing the key with changed parameters rejects. For supplied HTML, changed content or reported context also rejects; a new key can create a new run.

Event	Expected retained behavior	Business consequence
Process stops after a successful model response was durably stored	Same-run recovery can reuse the compatible retained response, then perform the remaining admission checks.	Previously received work need not be repeated solely because the worker restarted.
Welcome extraction completes with its cashout conflict	Result and pending terminal notification are committed together. Execution can be complete while coverage includes an unresolved term.	The available evidence stays usable without turning uncertainty into a value.
Receiver accepts the notification, but its acknowledgement is lost	Bounded retries send the same delivery identity and retained snapshot.	Receiver can deduplicate; extraction is not run again.
Delivery remains unsuccessful	Authorized reads still expose the retained result; an explicit delivery retry is available within retention.	Delivery trouble does not change extraction status or erase the result.
An accepted run fails execution	It still receives one logical terminal notification per configured destination, with its failure outcome.	A client can distinguish failed work from a notification that has not arrived.

Execution, coverage and delivery answer separate questions: did the run finish, which requested facts/sources were supported, and did the receiver acknowledge its notification? Status and result reads create no new work. The result API and webhook refer to the same retained result, although their transport metadata may differ. Each authenticated integration uses its configured destination; ordinary requests cannot supply arbitrary webhook URLs.

Recovery reuse stays within the same run and agreed retention limits. If an external response was lost before durable storage, exactly-once external calls cannot be promised. A fresh run processes its own input; this is not a cross-run response cache.

The consumer owns durable acknowledgement, duplicate handling, import precedence and catalogue mapping. Correlation, scope and request-order metadata allow it to compare relevant results without treating every market or field set as interchangeable. Import, editorial review and publication remain separate from parser delivery. The Payload collection review shows catalogue structures as a separate proposal, not an already connected receiver.

Selected field inventory

These are semantic fields selected for parser v1.1.1. The examples make their relationships concrete; they do not require every field to appear on every casino page. Each admitted value needs retained source support and the right entity, context, unit and period.

Family	Selected fields and meaning
Identity and profile	Display name; official URL; observed redirect/domain candidates; establishment year; operator label; casino platform labels. A casino year is not automatically a company's incorporation year.
Licence statements	Authority; jurisdiction; stated licence number/status/verification link. Publisher attribution survives; independent verification is separate.
Access and language	Stated restrictions and eligibility; website languages; explicit availability statements. Route, language, eligibility and observed access remain distinct.
Banking	Payment-provider labels; supported deposit/withdrawal direction; fiat/crypto currencies; minimum deposit; minimum withdrawal; maximum withdrawal with period. Method, direction and currency stay correlated.
Support and suppliers	Stated live-chat availability; support email; game-studio labels. Missing evidence does not become false or an exhaustive catalogue.
Offer identity and structure	Type, headline, stated audience, source identity and order; repeated deposit stages; separate cash and spin components. Structural IDs are not quoted source facts.
Cash bonus	Match percentage; maximum bonus award; minimum qualifying deposit; maximum bet; bonus-specific cashout cap. Maximum bet is included in the selected pack.
Wagering	Multiplier and base, including bonus, deposit plus bonus and spin winnings; explicitly supported no-wagering state.
Free spins	Count; spin value/currency; game restrictions; wagering and associated cap, bound to their own component.
Other offer conditions	Code; validity, expiry and wagering windows with their starting context; explicitly stated forfeitable/non-sticky conditions. Omission does not establish those booleans.
General terms: 16 definitions	Withdrawal fee, instalment schedule, method matching, processing window; deposit playthrough; inactivity trigger, period and charge; funds-protection claim; account-closure and balance-confiscation conditions; complaints process, dispute body, governing law and dispute deadline; withdrawal conditions affecting the bonus.
No-deposit and unlock: nine definitions	No-deposit amount; no-deposit maximum winnings; unlock count; increment value; wagering per increment; full-unlock wagering; unlock wagering base; permitted use of unlocked funds; withdrawal requirement. Shared currency and offer/stage/component meanings remain in use.
Cashback	Percentage; stated calculation/loss base; period; cap; qualifying conditions. Published terms, not a calculated player reward.

Unknown, explicit zero, explicit none, unlimited and not applicable are different states. Ambiguous currency stays unresolved rather than being inferred from language, market or a bare currency symbol. Unsupported observations may be retained within bounds for technical-author review, with exact source excerpts; they do not become admitted fields by acquiring a label.

What the evidence establishes

Evidence	What it supports	What it does not establish
Worked examples on this page	Review of desired values, units, nested relationships, source binding and unresolved outcomes.	Actual operator terms, model accuracy or a shipped parser.
Recorded local library experiment, 11 September 2026	Ajv accepted an added nested unlock object with repeated items under an updated schema, rejected it under the earlier schema and rejected a wrong nested value type. A JSON Logic nested condition distinguished deposit-based from bonus-based unlocks.	Extraction accuracy, source admission, generic mapping, activation, persistence or delivery. The same small runner tested library capabilities only.
Recorded retrieval experiment on one known operator site	HTTP and browser paths produced matching prepared text for its homepage and bonus terms. A model extracted five welcome-deposit stages and a wagering period; the test schema and six literal source-quotation checks passed.	Regional proxy access, broad discovery, Adaptive retrieval policy, JSON Logic, canonical money mapping, durable recovery, webhook delivery, throughput or operating cost.
Planned shared acceptance corpus	Six operator sites, up to 36 selected HTML pages, with two or three nominated regional routes on a subset; shared across all selected fields, dynamic actions and supplied-HTML cases. Every mandatory definition needs a human-checked positive case somewhere in that corpus.	A runtime six-site limit, launch-country list, universal success rate or a speed guarantee. The corpus is an acceptance-preparation bound, not completed evidence.

A supplied fragment can prove extraction from that input without proving automatic browser retrieval. Controlled cases can prove conflicts, scope and recovery behavior; live official captures must separately prove access on nominated routes. Empty output with a gap label cannot pass a required positive extraction case. Passing a schema and matching a quotation also cannot prove that the quotation supports the value's meaning or scope.

Source layouts, links, regional routes and model behavior can change. Definition maintenance and relevant reference checks remain necessary. This proposal establishes no unlimited site-fix allowance or support SLA, and no measured savings claim.

Review questions

In the welcome example, are stage, component, wagering base and the three kinds of limit clear enough for catalogue review? Which further source passage would you need to resolve the cashout conflict?
Do the payment rows and 16 general terms preserve the conditions your team needs, including period, trigger and attribution? Identify a field whose meaning would be lost during import.
Does Four-step release preserve the per-increment versus package distinction? Should a different source layout or unequal increments be a mandatory reference case?
Are the cashback base, exclusions, period and qualifications sufficient to describe the published offer without calculating a reward?
Does the supplied fragment outcome make its gaps clear, and does the targeted-run example distinguish unselected sources from failed selected sources?
For definition B, which human-checked values and source bindings must block activation if they change? Which consumer mapping would need a separate change?

Respond with this page's title and revision date, the relevant example/field, and acceptance, requested changes or deferral through the existing review process.

Recorded outcome

No decision recorded. Agreement on this document's examples would not approve implementation, integration, a delivery date or deployment.

Decision requested​

Read the examples​

Welcome offer: two stages with separate cash and spins​

Source passages​

Expected structured result​

Profile, banking and general terms​

A profile and two payment directions​

All 16 general-terms definitions​

No-deposit and repeated unlocks​

A no-deposit award with a withdrawal condition​

Four releases, with package totals preserved​

Cashback with its calculation base​

Two input modes and country context​

Reading an official URL​

A targeted run does not mean universal eligibility​

Supplied HTML creates its own result​

Change a definition without rebuilding the engine​

From a deposit field to a repeated unlock schedule​

Add an inactivity charge using existing value shapes​

Reuse the unlock shape for unequal releases​

Keep a condition inside its selected stage​

Read different wording into the same field shape​

Preserve conditional payment rows​

Catch a semantic regression in preview​

Preview, compare, then activate for future runs​

One retained result through recovery and delivery​

Selected field inventory​

What the evidence establishes​

Review questions​

Recorded outcome​