IDDAS is a deterministic protocol for identity-free activation, lineage-based attribution, and verifiable outcomes.

This document is the normative ruleset for the Instant Distributed Digital Activation System (IDDAS) Protocol - Core Rules.

It defines:

• What constitutes an activation
• How lineage is created and preserved
• When allocation occurs
• How allocation and payout are computed
• Which rules are fixed and non-negotiable
• How verification is performed
• How changes are versioned without retroactive effect

This document is authoritative. If any derivative explanation, implementation, interface, or summary is ambiguous, incomplete, or inconsistent, the rules in this document control.

Versioning posture

• The protocol is versioned.
• Changes, if any, apply prospectively and do not alter past outcomes.
• Active protocol versions are publicly identifiable and verifiable.

This document is not:

• A product or user interface specification
• An engineering or implementation guide
• A sales or marketing description
• A promise or guarantee of revenue, earnings, or outcomes
• A disclosure of internal thresholds, heuristics, or abuse detection logic
• A contract or negotiated commercial agreement

Products, interfaces, commercial terms, and implementations may vary, but they may not contradict, override, or weaken the rules defined in this document.

This protocol applies to any system, deployment, or outcome that claims IDDAS compatibility or references IDDAS-defined concepts, including but not limited to activations, lineage, allocation, settlement, or verification.

Specifically, this protocol applies to:

• Any system claiming IDDAS compatibility
• Any deployment using IDDAS-defined activation, lineage, allocation, or settlement rules
• Any outcome whose verification, attribution, or auditability references this protocol

Use of IDDAS-defined mechanisms, terminology, rules, or verification implies acceptance of the full protocol and its constraints.

Partial, selective, modified, or “inspired-by” adherence does not qualify as IDDAS-compatible. Systems that deviate from protocol-defined rules may not represent themselves as compliant, interoperable, or compatible with IDDAS.

This document is the highest authority governing IDDAS rule behavior.

Precedence order:

• IDDAS Protocol - Core Rules (this document)
• Formal technical specifications derived from this document
• Public website summaries
• FAQs and explanatory materials
• Marketing content, presentations, or verbal explanations

All lower-precedence materials must conform to this document. If any lower-precedence material is ambiguous, incomplete, or conflicts with these rules, this document prevails.

All outcomes defined by this protocol are deterministic when derived from published rules applied to a cryptographically committed set of accepted activations.

The Verification Layer independently recomputes eligibility and allocation by applying the published, versioned rules to the committed activation set and the corresponding rule version in effect at the time of activation.

• No outcome relies on opaque flags, internal status fields, or undisclosed attributes (including but not limited to internal eligibility indicators) as trusted inputs.
• Determinism applies to outcomes derived from committed inputs and published rules, not to raw traffic, attempted interactions, or events that are not accepted into the committed activation set.

No discretionary overrides are permitted.

No subjective interpretation is applied after revenue exists.

If an outcome cannot be derived from committed inputs and published rules, it does not qualify as a valid protocol outcome.

This protocol defines rules, not software.

• Multiple implementations may exist, including first-party, third-party, or derivative implementations
• Implementations may differ in architecture, performance, infrastructure, or user interface
• Implementations must not alter, reinterpret, or weaken protocol-defined behavior

Protocol correctness, validity, and verification are independent of any specific implementation.

All protocol rule changes must be versioned.

Rules:

• Each version has a unique identifier and effective date
• Changes apply prospectively unless explicitly stated otherwise
• Settled outcomes remain verifiable against the protocol version in effect at the time they occurred
• No change may silently alter allocation, eligibility, verification, or payout behavior
• New versions may coexist with prior versions for verification and audit purposes

Protocol history is immutable. Past outcomes are never rewritten.

All protocol-defined events are recorded in an append-only manner.

• Recorded events cannot be deleted
• Recorded events cannot be overwritten
• Corrections or adjustments occur only through the recording of additional events

This immutability ensures that lineage, verification, and outcomes remain auditable and reproducible over time, independent of implementation.

All derivative materials, including but not limited to websites, FAQs, white papers, documentation, and sales materials:

• Must accurately reflect the current protocol version they reference
• Must not introduce new rules or requirements
• Must not reinterpret, weaken, or override fixed protocol behavior

If a derivative document is ambiguous, incomplete, or requires clarification, the protocol must be consulted. Informal explanations or derivative materials do not amend, supplement, or replace this document.

This protocol intentionally does not define or govern the following:

• Business strategy or commercial positioning
• Pricing and commercial terms beyond protocol-defined neutrality constraints
• Commercial minimums, discounts, or negotiated contractual terms
• Identity systems beyond optional anchoring mechanisms
• Regulatory compliance requirements specific to any jurisdiction

These concerns are external to protocol correctness and are addressed at the implementation, operational, or commercial layer. Their existence or variation does not affect protocol validity, determinism, or verification.

• Activation-before-identity is foundational.
• An activation is a verified, intentional human entry into the system.
• Passive exposure does not count as activation.
• Activation is not a conversion.
• Conversions create revenue.
• Activations create lineage and eligibility.
• No speculative value is created.
• No discretionary overrides exist.
• Allocation is deterministic and rule-based.
• Rules are versioned and non-retroactive.
• Verification replaces trust.

Pricing is not defined by this protocol.

The IDDAS protocol does not set, mandate, negotiate, or enforce:

• prices
• rates
• tiers
• discounts
• minimums
• commercial terms
• billing structures

Pricing is defined exclusively by the Brand or implementation operating within the protocol (e.g., CandleMe), subject to the following protocol constraints:

• Pricing MUST NOT alter activation eligibility
• Pricing MUST NOT alter lineage formation
• Pricing MUST NOT alter allocation logic or outcomes
• Pricing MUST NOT introduce discretionary overrides
• Pricing MUST NOT affect verification or determinism

Pricing influences capacity access only, as defined in Section 8, and has no effect on attribution, eligibility, or outcome computation.

Payment handling is external to protocol logic.

The protocol defines when outcomes are computed, not how or when payments are collected.

Accordingly:

• Activation behavior is independent of payment status
• Lineage formation is independent of payment status
• Allocation computation is independent of payment status
• Verification does not rely on payment state

Payment collection, invoicing, settlement timing, and commercial enforcement are implementation- or contract-defined and MUST NOT modify any protocol-defined behavior.

Payment is an operational concern, not a protocol prerequisite.

• CandleMe is a consumer-facing implementation built on IDDAS.
• It demonstrates activation-before-identity under real conditions.
• The candle appears already lit on load.
• Saving extinguishes the flame.
• Refreshing is idempotent.
• Sharing creates a new activation.
• Loss is acceptable.
• CandleMe is not the protocol.

To reduce adoption friction while preserving rule integrity, the system provides a one-time activation credit.

This credit exists to allow organizations to observe the system in real conditions without procurement overhead or sales negotiation.

• Each organization receives a one-time activation credit of 100 activations.
• Credits are one-time only.
• Credits are non-renewable.
• Credits are non-transferable.
• Credits are applied automatically.
• Credits follow the same rules, pricing, attribution, and verification as paid activations.

Credits pre-fund standard activations.

When the credit is exhausted, standard billing begins automatically. Pricing and rules do not change.

Activation credits do not:

• Change pricing
• Change activation behavior
• Create special cases
• Introduce negotiation
• Enable unlimited usage
• Alter allocation or lineage
• Modify protocol rules

Credits exist solely to reduce initial adoption friction.

• Credits are policy, not promotion.
• No dollar values are presented.
• No urgency language is used.
• Credits are not framed as free offers or trials.
• The tone is calm, declarative, and rule-based.

Message conveyed:

• "The rule is finished. You can see it work."

This structure:

• Preserves elegance
• Prevents gaming
• Eliminates discretion
• Simplifies adoption
• Protects the rule at scale
• Allows small and large deployments to self-select naturally
• Ensures that payment reflects real engagement only

All conversion selections are subject to the protocol’s definition of real, net-settled revenue.

The protocol allocates value only when real revenue is created.

For revenue to qualify as real revenue under this protocol, it must be:

• Received and net-settled
• Measurable in objective units (currency or equivalent)
• Attributable to a completed conversion event
• Ultimately satisfy net-settlement conditions as defined later in this constitution

Speculative value, intent signals, or uncompleted actions do not qualify.

If no real revenue exists, no allocation occurs.

The protocol does not create, assign, or imply speculative value.

Actions, attention, participation, or effort alone do not generate allocatable value. Value exists only after a measurable conversion outcome occurs.

The protocol does not:

• Promise future earnings
• Assign notional credit
• Create implied entitlement

All allocation outcomes are deterministic.

Given:

• A defined revenue amount
• A recorded lineage
• A published allocation rule

The resulting distribution is uniquely determined.

No randomness, negotiation, discretion, or subjective interpretation is permitted in allocation computation.

No participant, operator, administrator, or third party may override protocol-defined outcomes.

Once inputs are recorded:

• Eligibility cannot be altered
• Allocation cannot be adjusted
• Outcomes cannot be rebalanced

Discretion is excluded by design.

Protocol behavior is transparent by construction.

Transparency includes:

• Published rules
• Versioned changes
• Verifiable inputs
• Auditable outputs
• Verifiable allocation and settlement outcomes

Participants do not rely on trust in the operator. They rely on the visibility and determinism of the system.

Revenue (R) is the amount of qualifying economic value generated by a conversion event, as defined by the protocol.

For revenue to qualify as R, it must be:

• Measurable
• Attributable to a recorded lineage
• Non-speculative
• Settled or irrevocably committed through an implementation-defined settlement mechanism

Revenue represents gross economic value created by a conversion. Revenue is not commission and is not allocated directly to participants.

Authorizations, impressions, intent signals, or reversible activity do not qualify as revenue.

If R = 0, no allocation occurs.

A commission pool is an implementation- or contract-defined portion of qualifying revenue made available for allocation to contributors.

The protocol does not define:

• whether a commission pool exists
• the size of a commission pool
• revenue shares, percentages, or formulas
• platform fees or retained amounts

The protocol defines only:

• which activation events are eligible
• how lineage is constructed and preserved
• when allocation is triggered
• how allocation outcomes are computed deterministically once qualifying revenue exists

If a commission pool is defined by a Brand or implementation, allocation within that pool MUST follow protocol rules for eligibility, lineage, determinism, and non-discretion.

If no commission pool is defined, the protocol still records lineage and verifies outcomes, but no participant allocation occurs.

A Brand is the entity responsible for a deployment within IDDAS.

A Brand may be a company, organization, individual, or other legal or natural person.

The Brand:

• Defines business intent and selects qualifying conversion events within protocol constraints
• Provides the bank account where qualifying revenue is received
• Pays for activations generated through the deployment
• Defines whether a commission pool exists and its size

A Brand operates within the IDDAS protocol and does not control allocation, lineage, or settlement rules or mechanisms.

A candle is a specific activation object representing a human-facing ritual of engagement.

• A candle is an implementation artifact, not a protocol requirement
• Candle interactions may result in one or more protocol-defined activation events

An open candle is a candle that is not bound to a persistent deployment or environment.

Open candles are ephemeral by default and may exist without long-term persistence, enterprise configuration, or integration.

Open candles may still generate valid activation events and lineage under the protocol.

An anchored candle is a candle that is bound to a persistent deployment or environment.

Anchored candles are defined at the Brand or deployment level and may support extended behavior such as persistence, enterprise configuration, analytics, or integration.

Anchoring is a protocol state and is independent of individual participant actions.

An activation event is a verified, intentional entry into the system initiated by a person.

An activation event occurs when a person deliberately:

• Scans a code
• Opens an activation link
• Enters an activation flow

An activation event creates a recorded lineage entry and establishes eligibility for allocation if a qualifying conversion occurs.

Passive exposure does not qualify.

Lineage is the ordered, append-only set of activation events that led to a conversion event.

Lineage:

• Reflects propagation, not claims or assertions of credit
• Is formed automatically through recorded activation events
• Cannot be edited, reordered, or selectively pruned
• Is permanent once recorded

Lineage determines eligibility for allocation if qualifying revenue is generated. It does not guarantee outcomes, compensation, or value.

Lineage exists independently of identity, accounts, or participant intent, and is enforced deterministically by the protocol.

The originator is the first activation event in a lineage.

The originator establishes the initial propagation context and is included in allocation if a qualifying conversion occurs.

An intermediate is any activation event in a lineage that is neither the originator nor the activation event immediately preceding a conversion event.

Intermediates may contribute to propagation and are eligible for allocation according to the published allocation rule if a qualifying conversion occurs.

The closer is the activation event immediately preceding a conversion event.

The closer does not receive preferential treatment unless explicitly defined by the published allocation rule.

A conversion event is a completed action that generates real revenue (R).

Examples include:

• A purchase
• A paid commitment
• Any other defined revenue-generating outcome

Conversion events trigger allocation when qualifying revenue exists.

Activation events alone do not.

An environment is the physical, digital, or operational context within which activations occur.

An environment may represent:

• A venue, location, or facility
• A physical surface or object
• A digital property or interface
• A campaign, program, or offering
• A defined deployment, tenant, or enterprise context

Environments bind activations to a specific deployment and may define configuration, behavior, pricing, persistence, or integration settings applicable to that context.

Environments provide attribution and operational context but do not alter lineage formation, allocation logic, or protocol-defined settlement rules.

A candle is an activation instrument within the IDDAS protocol that represents a bounded context for activation, propagation, and allocation.

A candle is not:

• a user
• an account
• a seat
• an identity

A candle represents a specific context under which activation events may occur and lineage may form.

That context may include, but is not limited to:

• representing a person
• representing a business or brand
• representing an offer or campaign
• representing an environment or location

Each candle operates independently and participates in lineage formation and allocation strictly according to the rules of this protocol.

Candles are intentionally non-scarce.

The protocol does not impose a limit on the number of candles that may be created or anchored by any individual or entity.

This design choice is intentional and foundational:

• outcomes are scarce
• value is allocated only after verified outcomes
• candle creation alone does not create eligibility or entitlement to value

Scarcity is enforced at the level of verified activation events and conversion events, not at the level of candle creation or anchoring.

Any individual or entity may anchor multiple candles simultaneously.

There is no restriction preventing:

• one person from anchoring many candles
• one entity from being represented by many candles
• one representative from carrying candles for multiple entities

This enables real-world representation patterns, including affiliates, agents, promoters, and delegated representatives.

Each candle maintains its own independent lineage and does not share attribution or eligibility with other candles unless explicitly connected through valid activation events.

Anchoring a candle establishes its origin point for lineage construction.

The anchor:

• defines the initial position in the lineage
• does not imply ownership of outcomes
• does not guarantee allocation

Anchoring a candle does not, by itself, create value, eligibility, or entitlement.

Value allocation occurs only after a qualifying conversion event, as defined elsewhere in this protocol.

Candles may propagate through eligible activation events.

Propagation:

• appends entries to the candle’s lineage
• is append-only
• cannot overwrite or remove prior lineage entries

Propagation order reflects contribution sequence, not time of claim, assertion, or identity.

Only eligible activation events may create lineage entries. Eligibility requirements are enforced deterministically by the implementation.

Each candle is independent.

Rules of independence include:

• lineages do not merge across candles
• outcomes are computed per candle
• allocations are computed per conversion event per candle

Actions taken on one candle have no effect on:

• other candles anchored by the same person
• other candles within the same environment
• other candles representing the same entity

This isolation ensures deterministic attribution, prevents cross-contamination of allocation logic, and preserves protocol correctness under scale.

A lineage is the ordered, append-only sequence of eligible activation events associated with a specific candle.

For a given candle, the lineage is represented as:

L = {a1, a2, …, an}

Where:

• a1 is the originator activation event (the first eligible activation in the lineage)
• each ai is a distinct eligible activation event
• i is the index position of an activation event within the lineage (i ∈ [1, n])
• n is the total number of lineage entries at the time of conversion

Lineage order reflects propagation sequence, not time of claim, attribution assertion, identity, or payout request.

Lineage is strictly append-only.

Once an entry is added to a lineage:

• it cannot be removed
• it cannot be reordered
• it cannot be overwritten
• it cannot be reassigned

There are no discretionary overrides, manual edits, or post-hoc adjustments to lineage state.

This property is essential to deterministic allocation, verification, and auditability.

Lineage entries are created only by eligible activation events.

An eligible activation event is an implementation-recognized action that:

• meets published eligibility criteria
• is verifiable by the implementation
• occurs within the scope of the candle and its environment

Examples of eligible activation events may include, but are not limited to:

• verified placements
• verified scans
• verified introductions
• verified handoffs

Eligibility criteria and verification methods are enforced deterministically by the implementation and may evolve through versioned protocol changes.

The protocol does not require public disclosure of implementation details for eligibility enforcement, provided enforcement remains deterministic and non-discretionary.

The following behaviors are explicitly prohibited and produce no lineage entries:

• self-appending without a qualifying activation event
• repeated appending by the same actor without new eligibility
• artificial looping or circular propagation
• appending after a conversion event for the purpose of capturing allocation

Any attempted activation that does not meet eligibility criteria is ignored for lineage purposes and has no effect on allocation.

A lineage is evaluated for allocation at the moment a conversion event occurs.

Only lineage entries present at the time of conversion are eligible for allocation from that conversion event.

Entries appended after a conversion event:

• do not participate in that conversion
• may participate in future conversion events, if any

Each conversion event is evaluated independently and produces its own allocation outcome.

Lineage is scoped to a single candle and a single environment.

Rules:

• lineage does not cross candle boundaries
• lineage does not cross environment boundaries
• conversion events are evaluated within their originating environment

This ensures isolation, prevents attribution leakage, and maintains deterministic allocation and verification outcomes.

The system may expose lineage position to participants.

Participants may be able to see:

• whether they are in a lineage
• their relative position at a given time

However:

• lineage position does not guarantee allocation
• allocation is determined only at conversion
• no participant can reserve, lock, or claim a future position

Visibility does not confer rights, priority, or entitlement.

Allocation occurs only after a verified conversion event produces real, net-settled revenue.

The protocol does not create speculative value. Allocation is strictly downstream of measurable outcomes.

IDDAS defines and enforces the core rules of the system. These rules are fixed, versioned, and applied uniformly across deployments.

• Defines what qualifies as a valid activation
• Defines what qualifies as real revenue
• Defines how lineage is formed and preserved
• Defines how allocation outcomes are computed once qualifying revenue exists
• Computes allocation outcomes deterministically
• Prevents discretionary overrides, selective treatment, or retroactive changes

IDDAS does not negotiate outcomes, adjust distributions, or intervene on a case-by-case basis. Once protocol-defined inputs are recorded, outcomes follow the rules exactly.

A Brand is the organization, entity, or individual running a deployment on IDDAS.

• Selects which of its qualifying business events constitute conversion events, within the protocol’s definition of real revenue
• Provides the bank account where qualifying revenue is received

Brand discretion exists only before revenue is created and only within protocol-defined constraints.

Brands cannot:

• Redefine what qualifies as real revenue
• Override, edit, or reorder lineage
• Collapse distribution to a single party when multiple contributors exist
• Selectively exclude contributors from allocation
• Alter outcomes after revenue is created

This protocol defines eligibility, lineage, and deterministic outcome computation. It does not define pricing, revenue sharing, fees, commission structures, payout thresholds, or settlement mechanisms. Such terms, if any, are implementation- or contract-defined and do not alter protocol validity.

CandleMe is one implementation built on top of IDDAS.

CandleMe may define its own business terms, select qualifying conversion events, and provide its own bank account like any other Brand.

CandleMe has no special privileges within the protocol and is subject to the same rules, constraints, and enforcement as all deployments.

Allocation outcomes are deterministic when defined by published rules applied to the recorded lineage and qualifying events.

For any conversion event:

• allocation depends on lineage state and published rules
• no hidden parameters are permitted
• there are no discretionary overrides

For each conversion event:

• allocation outcomes are referenced
• payout amounts are recorded as ledger entries

Payout ledger entries are provisional until the associated revenue is confirmed as net-settled.

If revenue fails to settle, is reversed, or is invalidated prior to settlement finality:

• the corresponding payout ledger entry is voided or reversed
• no allocation is finalized for that conversion event

Settlement status affects payout finality only. It does not modify lineage, eligibility, or recorded activation events.

The timing of payout recording or disbursement does not affect:

• allocation outcomes
• lineage eligibility
• determinism of results

Allocation is computed at the moment a qualifying conversion occurs. Payout execution may occur later without altering any protocol-defined outcome.

No participant, operator, or implementation may:

• modify payout amounts after allocation is computed
• reorder or rebalance payouts
• selectively accelerate or delay payouts to influence outcomes

All payout handling must reflect the deterministic allocation results produced by the protocol.

The protocol supports self-serve operation by default, and introduces objective, capacity-based gating only when enterprise-scale throughput is requested.

The protocol supports self-serve operation by default.

Self-serve operation includes:

• creating and anchoring candles
• propagating candles through eligible activation events
• generating conversion events at ordinary scale

Self-serve operation does not require:

• contracts
• minimum commitments
• human approval
• enterprise classification

Self-serve operation remains available until enterprise-scale capacity is requested.

Scale is determined by requested capacity, not by participant identity.

The protocol does not classify participants as enterprise or non-enterprise.

Scale gating is triggered only when a participant requests capacity, throughput, or features that exceed self-serve limits.

Scale is governed structurally, not reactively. Certain capabilities require predefined capacity and are only available when sufficient activation credits or prepaid balances exist.

These capabilities may include:

• large environment deployments
• high-volume activation issuance
• bulk or programmatic operations
• advanced environment-level analytics

No monitoring, classification, detection, or discretionary escalation occurs. Availability is determined solely by declared capacity and deterministic rules. When prepaid credits are exhausted, enterprise-scale capabilities may be gated, while standard usage may continue under metered billing as defined in Sections 7.6 and 8.6.

Certain environment types inherently require enterprise-scale capacity.

Examples include:

• stadiums and arenas
• large venues
• transit hubs
• city-wide or regional deployments

When such an environment type is requested, enterprise-scale capacity requirements apply before activation may proceed.

No manual classification or subjective approval is performed.

Enterprise-scale capacity may require a minimum upfront commitment.

The protocol does not define the amount of any minimum commitment.

Where a minimum exists, it:

• is satisfied through prepaid usage credits
• is applied under uniform, non-negotiated rules
• exists solely to provision capacity, verification, and settlement resources proportional to the requested scale

Prepaid credits are consumed by:

• candle creation
• activation verification load
• environment-level operations
• other usage-based costs defined by the implementation

Credits are consumed automatically as usage occurs.

When prepaid credits are exhausted, usage continues under metered billing and additional charges are applied automatically.

Minimum commitments are not refundable.

Credits represent prepaid capacity, not a membership fee, license, or deposit.

This rule eliminates discretionary refund handling and ensures continuity of operation.

Scale requirements are disclosed progressively.

Participants encounter scale gating only when:

• attempting to exceed self-serve limits
• requesting enterprise-scale capabilities

The protocol imposes no upfront friction on experimentation, evaluation, or early adoption.

Pricing, where applied by an implementation, is defined to support capacity provisioning without influencing economic outcomes.

The pricing model is designed to:

• charge for capacity and instruments, not outcomes
• avoid penalizing success or scale
• remain predictable and transparent
• scale from individual usage to large deployments
• avoid negotiation or discretionary pricing

Pricing does not alter lineage, allocation rules, or payout mechanics.

Candles may be priced as individual activation instruments.

Each anchored candle may incur a fixed creation cost.

Pricing may be applied at the time of candle creation.

Candles may be configured with predefined expiry parameters selected at creation time. Expiry parameters are fixed, declared in advance, and applied deterministically. Once a candle is created, its expiry cannot be modified, extended, or overridden. Expiry exists solely to bound activation eligibility and does not alter attribution, allocation, or pricing rules.

Pay-per-candle pricing may support:

• affiliates
• individual representatives
• small businesses
• experimental and exploratory usage

For higher-volume usage, implementations may support open-ended metered accounts.

Metered accounts:

• track usage over time
• automatically bill for usage beyond prepaid credits
• do not impose seat limits or user-based pricing

Metered billing applies only after usage occurs.

There are no subscription tiers tied to identity, role, or participant classification.

Enterprise-scale capacity may require prepaid credits to ensure availability, throughput, and operational stability.

Prepaid credits:

• are paid upfront
• convert directly into standard activation credits
• are non-refundable once consumed
• do not change pricing, attribution, allocation, or verification rules

This protocol does not define a numeric minimum commitment amount; where enterprise-scale capacity requires a minimum, it is satisfied through prepaid credits under uniform, non-negotiated rules.

Prepaid credits represent capacity within the system.

Credits may be consumed by:

• candle creation
• activation verification
• environment-level operations
• other usage-based costs defined by an implementation

Credits are deducted automatically as usage occurs.

Unused credits remain available until consumed.

When prepaid credits are exhausted:

• usage may continue without interruption
• additional usage may be billed under metered pricing

Service may not be suspended solely due to credit exhaustion, except where required for risk control, system integrity, or compliance.

Pricing decisions do not affect lineage formation, allocation outcomes, payout eligibility, or deterministic results.

All participants are treated identically under protocol-defined rules regardless of pricing model, commitment size, deployment scale, or commercial arrangement.

Pricing influences capacity access only and has no effect on attribution, eligibility, or outcome computation.

Only eligible activation events may create lineage entries or participate in allocation.

Eligibility exists to:

• preserve attribution integrity
• prevent artificial or spam propagation
• ensure that value allocation reflects real contribution

Eligibility rules apply uniformly across all environments, candles, and participants.

An eligible activation event is an action that:

• is recognized by the implementation
• occurs within the scope of a specific candle and environment
• meets protocol-defined contribution criteria
• is verifiable using implementation-enforced methods

Activation events that do not meet eligibility criteria are ignored for lineage and allocation purposes.

Verification is required for all activation events that contribute to lineage.

Verification may include, but is not limited to:

• implementation event validation
• device or session confirmation
• contextual consistency checks
• timing and frequency constraints

Verification is enforced programmatically.

No activation event is eligible without verification.

The protocol enforces participation constraints to prevent abuse.

Such constraints may include:

• limits on repeated participation by the same actor within a lineage
• prevention of circular or looping propagation
• restrictions on self-referential activation patterns

The protocol does not require persistent identity disclosure to participants in order to enforce these constraints.

Anti-abuse enforcement is integral to eligibility determination.

The protocol may:

• reject ineligible activation events
• ignore invalid or non-conforming propagation attempts
• invalidate activation events that fail verification

Anti-abuse enforcement operates deterministically and does not alter valid lineage entries or allocation outcomes.

Internal safeguard, abuse-prevention, and validity-gating mechanisms may influence which interactions qualify as accepted activations and are included in the committed activation set.

The specific implementation details of these safeguards are intentionally not publicly disclosed in order to preserve their effectiveness and prevent circumvention.

This non-disclosure does not violate determinism because verification operates on the accepted activation set and the published protocol rules, not on raw traffic or rejected interactions.

Safeguards are structural and rule-bounded. While certain detection or evaluation heuristics may remain private, their function is limited to admission into the committed set and does not alter published rules, outcomes, or allocation once an activation is accepted.

Only activation events that pass eligibility and verification:

• appear in lineage
• participate in allocation
• receive payouts

Ineligible or unverified events receive no allocation and no payout.

If a candle has only one eligible participant at the time of a conversion event, allocation is resolved deterministically according to the applicable published rules for that deployment or implementation.

If a lineage contains an originator and a closer with no intermediates, allocation is resolved deterministically according to the applicable published rules. No discretionary reassignment occurs.

If a lineage contains multiple intermediates, allocation outcomes are determined by the applicable published rules. Increasing lineage length does not, by itself, create additional allocatable value.

Any activation attempts occurring after a conversion event:

• do not affect allocation for that conversion
• do not retroactively modify lineage
• may participate only in future conversion events

Post-conversion appending produces no retroactive entitlement.

If multiple parties assert responsibility for a conversion:

• the system-recorded conversion trigger determines the closer
• manual claims or assertions are ignored

The protocol does not adjudicate subjective disputes.

If multiple conversion events occur from the same candle:

• each conversion event is evaluated independently
• allocation is computed separately for each event
• revenue is not double-counted

Accrued balances may combine across events for payout threshold purposes.

If a conversion event fails to settle:

• no allocation is finalized
• no payout is issued

If a transaction reverses after provisional recording but before payout:

• the allocation is reversed or netted
• accrued balances are adjusted accordingly

If an activation event is determined to be ineligible prior to settlement:

• the event is excluded from lineage
• allocation is recalculated if required
• no payout is issued for the ineligible event

If settlement has already occurred, reversal handling follows Section 6.

In the event of system faults or interruptions:

• incomplete activation events may be discarded
• incomplete conversion events produce no allocation
• completed and verified events remain authoritative

There are no discretionary reallocations due to system interruption.

An environment is a bounded operational context within which candles operate, lineage is constructed, and conversion events occur.

An environment may represent, for example:

• a location
• a venue
• a business unit
• a campaign scope
• a deployment boundary

Every candle operates within exactly one environment at any given time.

Environments are isolated from one another.

Isolation rules include:

• lineage does not cross environment boundaries
• conversion events are evaluated within a single environment
• allocation and payout are computed per environment

Actions in one environment have no effect on:

• lineage in other environments
• allocations in other environments
• payouts associated with other environments

This isolation ensures clarity, auditability, and deterministic outcomes.

A candle is associated with an environment at the time it is anchored.

Rules:

• a candle may not belong to multiple environments simultaneously
• a candle’s lineage remains scoped to its environment
• changing a candle’s environment creates a new operational context

Environment association defines context only and does not imply ownership, entitlement, or preferential treatment.

An environment progresses through defined lifecycle states.

Lifecycle states may include:

• creation
• configuration
• activation
• operation
• suspension
• deactivation

Lifecycle transitions are system-controlled and do not modify lineage, allocation, or payout rules.

Environments may be subject to capacity constraints based on:

• scale of deployment
• verification throughput
• activation volume
• analytics load

Capacity constraints are enforced automatically according to the Scale and Capacity Model defined in Section 7.

Requests exceeding environment capacity may require prepaid credits to provision the required throughput or operational load. This requirement is rule-based and does not alter pricing, attribution, allocation, or verification.

Certain operations occur at the environment level.

Environment-level operations may apply to candles and other activation instruments deployed within an environment.

These may include:

• bulk candle creation
• environment-wide analytics
• activation verification configuration
• capacity management

Access to environment-level operations may be gated by scale and capacity requirements.

The protocol enforces integrity within each environment.

Integrity enforcement may include:

• prevention of duplicate environments with conflicting scopes
• consistency checks between environment configuration and usage
• enforcement of environment-specific eligibility constraints

Integrity enforcement operates deterministically and does not alter valid lineage entries, allocation outcomes, or payouts.

Section Status

Section 11 defines how environments function as isolated operational contexts within the protocol.

Environment rules preserve determinism, auditability, and correctness at scale.

All protocol outcomes are governed by deterministic rules.

For any conversion event:

• lineage state
• allocation outcomes
• payout calculations

are derived mechanically from published rules and recorded events.

There are no discretionary adjustments, overrides, negotiations, or case-by-case decisions.

Allocation logic is rule-defined and invariant within a given protocol version.

Participants may inspect:

• role definitions
• eligibility conditions
• collapse or resolution rules
• conditions under which allocation occurs

Given identical inputs, the protocol always produces identical outputs.

The protocol maintains authoritative records of:

• candle anchoring
• accepted activation events
• lineage construction
• conversion events
• allocation and payout calculations

Records are retained to support auditability, internal verification, and authorized third-party review.

Sensitive operational or business data is not required to be publicly disclosed.

Cryptographic commitments (including hashes, Merkle roots, or version identifiers) may be anchored to a public blockchain to enable independent verification of correctness without exposing raw transactional data.

Implementations may provide participants visibility into:

• their participation in a lineage
• their role at the time of conversion
• their calculated allocation
• their accrued payout balance

Visibility does not confer control, discretion, or influence over outcomes.

The protocol minimizes disputes by:

• defining rules in advance
• enforcing rules automatically
• removing discretionary decision points
• evaluating outcomes solely on recorded events

Subjective claims, interpretations, or assertions do not affect protocol outcomes.

Transparency concerns which rules apply and how outcomes are computed.

Enforcement concerns how eligibility, verification, and abuse prevention are implemented.

The protocol discloses rule logic and outcome computation while not requiring disclosure of internal enforcement mechanisms that protect system integrity.

The protocol is designed to operate in mobile-first contexts.

Primary interactions are expected to occur on mobile devices, including:

• candle anchoring
• activation and propagation
• basic lineage visibility
• balance and payout awareness

Mobile interfaces prioritize speed, clarity, and minimal friction.

Desktop interfaces may complement mobile usage but are not required for protocol participation.

Desktop interfaces are intended primarily for administrative and oversight functions, including:

• environment administration
• analytics and reporting
• export and reconciliation
• billing and credit management
• oversight of large-scale deployments

Desktop access does not alter protocol rules and does not confer allocation, eligibility, or payout privileges.

Eligibility, verification, scale gating, allocation, and payout enforcement are designed to operate without routine human intervention.

Manual review may occur only in exceptional circumstances, including:

• regulatory or compliance requirements
• external legal obligations
• confirmed system faults

Manual review does not modify valid lineage entries, allocation outcomes, or payout determinations.

The following invariants must hold across all implementations:

• lineage is append-only
• conversion events are authoritative
• outcomes derive solely from recorded events
• allocation and eligibility are deterministic
• no discretionary overrides exist

Implementations may evolve, but these invariants must remain intact.

Protocol versions may evolve over time.

Changes to the protocol:

• must be versioned
• must not retroactively alter settled outcomes
• may introduce new features or constraints prospectively

Backward compatibility is preserved for existing candles and lineages unless explicitly deprecated by a future protocol version.

The protocol defines rules and guarantees.

Products and interfaces:

• enforce protocol rules
• expose protocol outcomes
• may vary in design, architecture, and presentation

Product changes do not modify protocol-defined behavior.

Public communication materials are derivative explanations of the protocol.

They exist to:

• explain behavior
• build confidence
• reduce confusion
• support adoption

Public materials do not define rules and do not override protocol behavior.

The protocol defined in Sections 1 through 13 is authoritative.

The public website may present simplified descriptions of the protocol.

Website summaries may include:

• high-level explanations of candles
• general descriptions of lineage and allocation
• statements regarding scale requirements
• non-technical descriptions of eligibility

Website content must:

• avoid operational thresholds
• avoid implementation details
• avoid negotiable or discretionary language

Acceptable phrasing includes:

• “Certain deployments require a minimum commitment.”
• “Allocation occurs only after real outcomes.”
• “Lineage entries require eligible activation events.”

The website must not publish:

• internal enforcement mechanisms
• anti-abuse thresholds
• verification logic
• internal system limits

FAQ content may expand on website summaries but remains non-normative.

FAQs may explain:

• common allocation scenarios
• the rationale for closer-dominant allocation
• natural dilution in long lineage chains
• why scale requires commitment

FAQs must:

• accurately reflect protocol rules
• avoid exceptions not defined in the protocol
• avoid promising discretionary outcomes

FAQs must not:

• introduce new rules
• contradict the protocol
• imply negotiability or special treatment

Product interfaces may display prompts and notices derived from protocol rules.

Examples include:

• scale gating notices
• minimum commitment prompts
• payout availability messages
• eligibility-related feedback

UI prompts:

• explain what is required
• do not explain how enforcement operates
• do not invite negotiation or exception handling

All UI messaging must remain consistent with protocol definitions.

Sales materials, partnerships, and external discussions may reference protocol behavior at a conceptual level.

Sales materials may:

• explain incentives
• describe economic structure
• explain why outcomes are deterministic and fair

Sales materials must not:

• promise custom allocation
• suggest rule overrides
• imply preferential treatment

Any commitment beyond protocol-defined behavior requires a formal protocol amendment.

In the event of conflicting explanations, the following precedence applies:

• This protocol document prevails
• Formal technical documentation follows
• Website summaries follow
• FAQs follow
• Marketing and sales materials follow

No derivative material may supersede or reinterpret the protocol.

Amendments to this protocol may be proposed only by the protocol steward.

No participant, partner, Brand, or deployment has the authority to alter protocol rules unilaterally.

All protocol changes must be versioned.

Each protocol version:

• is identified by a unique version identifier
• has a defined effective date
• applies prospectively unless explicitly stated otherwise

Historical versions remain authoritative for outcomes settled under those versions.

Protocol amendments do not retroactively alter:

• completed lineages
• settled conversion events
• finalized allocations
• paid or accrued payouts

Once revenue has settled and allocation has been recorded, outcomes are final under the protocol version in effect at the time of conversion.

Future protocol versions may introduce:

• new environment types
• new scale thresholds
• new pricing mechanisms
• new eligibility constraints
• new operational features

Such changes must:

• preserve core invariants
• avoid breaking existing candle behavior
• maintain deterministic allocation

The following invariants must be preserved across all protocol versions:

• allocation occurs only after real, net-settled revenue
• lineage is append-only
• allocation is deterministic and rule-based
• no discretionary overrides exist
• protocol rules apply uniformly across deployments

Features, environments, or behaviors may be deprecated in future versions.

Deprecation:

• is announced in advance
• does not invalidate existing outcomes
• applies only to future activity

Deprecated features may continue to operate for a defined transition period.

In rare circumstances involving:

• legal requirements
• critical security vulnerabilities
• system integrity threats

Temporary emergency changes may be applied.

Such changes:

• are narrowly scoped
• are documented retroactively
• do not alter settled outcomes

Emergency changes do not establish precedent and do not modify core protocol invariants.

Section Status

Section 15 defines how the protocol evolves while preserving determinism, fairness, and auditability.

Protocol authority is explicit, changes are controlled, and history is never rewritten.

Final Constitutional Summary

• Brands define business intent
• IDDAS defines and enforces the rules
• Once revenue exists, outcomes are deterministic

CANDLE SEALING SPEC v1.0

IDDAS Protocol - Canonical Commitment Event

The Candle Seal is the irreversible commitment action that converts a candle-based opportunity into a secured, verifiable deal object within IDDAS. This sealing specification applies only to enterprise-enabled implementations, and IDDAS compatibility does not require exposing Candle Sealing. This spec defines:

• The only valid sealing action
• The conditions under which sealing may occur
• The effects of sealing
• The boundaries that preserve the sacred candle

This spec is protocol law. UI, animation, and implementation must conform to it.

The only valid sealing action is:

In an enterprise-enabled context, the user performs a continuous 10-second hold on an unsealed candle with the flame off. Any interruption cancels the attempt silently, and completion seals immediately with no confirmation dialog.

There are:

• No alternative gestures
• No variants
• No shortcuts
• No secondary confirmation mechanisms

This action is canonical across enterprise-enabled implementations, devices, and environments.

A candle may be sealed only if all of the following are true:

• 1) The candle is unsealed
• 2) The flame is off
• 3) The user performs a continuous 10-second hold on the candle (or flame area) in an enterprise-enabled context

Notes:

• A candle may be sealed immediately upon receipt, or saved and sealed later while it remains unsealed.
• A candle with the flame on cannot be sealed.

Duration

• Hold duration: 10.0 seconds
• Must be continuous
• Any interruption cancels the attempt

Feedback during hold

• The system MUST provide calm, visible progress feedback
• No numeric countdown
• No urgency indicators
• No error messaging if released early

If the user releases early:

• The visual seal dissolves quietly
• No message is shown
• The candle remains unsealed

When the 10-second hold completes:

• 1) A single seal acknowledgment moment occurs
• 2) The candle is immediately and permanently sealed
• 3) A Seal Event is emitted (see 16.8)

There is no confirmation dialog. Completion of the hold is the commitment.

Once sealed:

• The candle cannot be unsealed
• The seal cannot be modified
• The deal cannot be renegotiated through the candle
• The sealing action cannot be repeated

This irreversibility is intentional and required. Sealing is equivalent to signing a contract, sealing a letter, or committing a transaction.

The candle remains:

• Visually a candle
• Conceptually a ritual object
• Free of enterprise UI elements
• Free of configuration controls

Sealing is a moment, not a mode switch. After sealing:

• The candle does not become an enterprise dashboard
• The candle does not expose settings or status panels
• The candle remains recognizable and unchanged

Upon successful sealing, the system MUST generate a single immutable Seal Event containing:

• Timestamp
• Candle ID
• Environment ID
• Lineage snapshot
• Rule version reference

This event is immutable, verifiable, and is the authoritative record of commitment.

Any post-seal steps occur outside the candle and outside this specification. This spec governs only the sealing action, its prerequisites, its irreversibility, and the resulting Seal Event.

The Candle Seal is not:

• A settings action
• A reversible choice
• A negotiable step
• A multi-gesture system
• A gamified interaction
• A shortcut or hidden trick
• A consumer-default feature

There is one candle. There is one seal.

This spec governs UI design, animation, engineering implementation, documentation, and website language. If an implementation conflicts with this spec, the spec wins.

Status

CANDLE SEALING SPEC v1.0 - LOCKED