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 beyond the fixed activation unit defined by the protocol
• 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.

• The pricing unit is the activation.
• The price per activation is fixed.
• Pricing is universal across industries, sizes, and use cases.
• There are no negotiated rates.
• There are no tiers.
• There are no discounts.
• There is no discretionary pricing.

If no activation occurs, no charge occurs.

• Billing is automatic.
• Payments are isolated from activation logic.
• Activation behavior never depends on payment status.
• Payment is an outcome, not a prerequisite.
• Event or deployment boundaries define billing windows.
• All records are auditable and verifiable.

• 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 the defined payment rails

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.

The platform share (α) is the fixed portion of qualifying revenue retained by IDDAS.

α is defined by the protocol and is invariant across deployments, Brands, and time.

The distribution pool (D) is the portion of qualifying revenue made available for participant allocation.

D is computed mechanically as:

• D = (1 − α) · R

If R does not qualify as revenue under the protocol, D does not exist.

A commission pool is a business-defined portion of the distribution pool.

The existence and size of a commission pool are defined by the Brand, subject to protocol constraints.

A commission pool:

• Is derived from the distribution pool, not directly from revenue
• Does not alter the definition of revenue
• Does not alter the protocol-defined platform share
• Is allocated according to protocol rules if multiple contributors exist

If no commission pool is defined, the distribution pool may be allocated according to Brand business logic, provided protocol constraints on lineage, determinism, and non-discretion are not violated.

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, settlement rules, or payment rails.

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 system.

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 a system-recognized action that:

• meets published eligibility criteria
• is verifiable by the system
• 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 system 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.

Let:

• R = net-settled revenue generated by a single conversion event

If R = 0, no allocation occurs.

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

The platform fee is fixed.

Let:

• R = real revenue generated through the system
• α = 0.30

Platform allocation:

Platform fee = α · R

This percentage is invariant across:

• industries
• environments
• partners
• time

There are no negotiated or per-client platform economics.

After the platform fee is applied, the remaining revenue is:

N = (1 − α) · R

Therefore:

N = 0.70 · R

This remainder represents revenue retained by the brand after the platform fee. It is not automatically distributed and is not acted upon by the protocol unless the brand explicitly defines a commission pool.

The brand may define a commission pool as a percentage of the post-platform remainder.

Let:

• c = brand-defined commission rate, where 0 ≤ c ≤ 1

The commission pool is:

C = c · N

Important clarifications:

• The commission rate c is set solely by the brand.
• The platform does not set, negotiate, or promise c.
• C may be zero.
• Only C is subject to lineage-based allocation under this protocol.
• If C = 0, no commission allocation occurs, regardless of lineage.
• Any portion of the post-platform remainder not designated by the brand as a commission pool remains with the brand.

The protocol does not allocate, restrict, or otherwise act upon this remainder. Its sole role is to deterministically allocate the brand-defined commission pool, if any, according to lineage.

For a given conversion event, lineage entries are classified as follows:

• Originator - the first lineage entry a₁
• Closer - the lineage entry aₖ that triggers the conversion event
• Intermediates - any lineage entries between the originator and the closer

Only lineage entries present at the moment of conversion are considered.

The allocation model applies only to the commission pool C.

Unless otherwise specified by a collapse rule:

• Closer allocation = 0.70 · C
• Originator allocation = 0.15 · C
• Intermediate pool = 0.15 · C

There is no last-touch discretion.

The closer is determined solely by the system-recorded conversion trigger.

The originator allocation is fixed and does not dilute based on lineage length.

If intermediates exist between the originator and the closer, a fixed intermediate pool is allocated and divided equally among those intermediates.

Let the lineage for a conversion be:

L = {a1, a2, ..., ak}

Where:

• a1 is the originator
• ak is the closer
• a2 through a(k-1) are intermediates (if any)

Let:

m = k - 2, the number of intermediates (excluding originator and closer)

The total intermediate pool is fixed at:

0.15 · C

Each intermediate receives:

(0.15 · C) / m

Intermediates do not receive weighting based on position, timing, or identity.

Originator and closer allocations are defined separately and are not part of the intermediate pool.

If m = 0 (no intermediates), the intermediate pool is reassigned as defined in the no-intermediate scenario.

Single-participant case

If the originator is also the closer:

The originator receives 100 percent of C.

No-intermediate case

If the lineage contains an originator and a closer with no intermediates:

Originator receives 0.30 · C

Closer receives 0.70 · C

The unused intermediate pool is reassigned to the originator in this case.

The allocation function is deterministic and published.

For any conversion event:

• allocations are computed solely from lineage position and fixed parameters
• no hidden parameters are permitted
• the sum of all allocations equals C
• there are no discretionary overrides

Assume:

Real revenue from a conversion is: R = $100

Platform share is fixed at: α = 0.30

Brand-defined commission rate is: c = 0.20

Step 1: Platform share

Platform allocation = α · R = 0.30 · $100 = $30

Step 2: Commission pool (brand-defined)

The commission rate applies to revenue R:

C = c · R = 0.20 · $100 = $20

Step 3: Lineage-based allocation of the commission pool

The protocol allocates only C according to the lineage allocation model:

• Originator pool: 0.15 · C
• Intermediate pool: 0.15 · C (if intermediates exist)
• Closer pool: 0.70 · C

The remainder of revenue after platform share and commission is retained by the brand and is not allocated by the protocol.

Note: This example is illustrative only. The protocol’s allocation math operates deterministically on the declared values of R and c, and on the lineage L at the time of conversion.

IDDAS is a rule-defined activation and allocation system. It separates business discretion from protocol enforcement to ensure outcomes remain fair, deterministic, and verifiable at scale.

This section defines the roles within IDDAS and the boundaries that govern them.

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

• Defines what qualifies as a valid activation
• Defines what qualifies as real revenue
• Defines how lineage is formed and preserved
• Defines how allocation is computed once revenue exists
• Defines the settlement and payment rails used across all deployments
• Enforces a fixed platform fee
• Executes allocation and payout 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
• Defines whether a commission pool exists and its size
• Provides the bank account where qualifying revenue is received
• Pays for activations generated through the deployment

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
• Modify or bypass settlement or payment rails
• Alter outcomes after revenue is created

Once a commission pool is declared and qualifying revenue exists, allocation is enforced by the protocol without discretion.

Commission pools are defined by the Brand as a percentage of qualifying revenue derived from the protocol-defined distribution pool.

Allocation within any commission pool is defined exclusively by the protocol.

If a single contributor exists in a lineage, that contributor receives the full distribution pool.

If multiple contributors exist, the pool is allocated deterministically according to the protocol’s published allocation rules.

Brands do not assign individual payout percentages to participants. Distribution is computed solely from lineage and fixed parameters.

IDDAS defines the payment and settlement rails.

These rails are fixed, standardized, and identical across deployments.

Brands do not select, customize, bypass, or intervene in settlement mechanisms.

Once a Brand deploys on IDDAS, revenue settlement, platform fees, allocation, and payouts follow the protocol-defined rails exactly.

This structure removes discretion, prevents intervention, and ensures outcomes remain auditable and verifiable over time.

CandleMe is one Brand and one implementation built on top of IDDAS.

CandleMe defines its own business terms, selects qualifying conversion events, provides its own bank account, and pays for activations like any other Brand.

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

Definition

An Infrastructure Originator (IO) is a protocol-level lineage root that authorizes and anchors one or more activation surfaces under this protocol, where such surfaces later produce verified activations.

Infrastructure Originator status is not granted, claimed, negotiated, or approved. It emerges solely through downstream protocol-valid activations attributable to activation surfaces anchored under the originator’s lineage root.

Infrastructure Originators may authorize or enable deployment without physically creating, installing, operating, or managing the activation surfaces themselves. Physical deployment and operational execution may be performed by third parties, organizations, operators, integrators, or internal teams acting under the authorized deployment root.

Origination is structural, not behavioral. Attribution follows lineage, not labor.

Creating an activation surface alone confers no status and no entitlement. Only verified downstream activations trigger Infrastructure Originator attribution and allocation.

Definition - Activation Surface

An activation surface is any protocol-issued entry mechanism that enables intentional activation by one or more independent participants, regardless of medium.

Activation surfaces may exist in physical, digital, or hybrid environments and may be deployed wherever intentional human entry can occur.

Activation surfaces include, but are not limited to:

• QR codes deployed on physical objects, printed media, signage, packaging, tickets, badges, or installations
• URL-based activation links distributed digitally or embedded in software, websites, applications, emails, messages, or APIs
• Screens, displays, kiosks, terminals, tablets, projectors, or other visual interfaces capable of presenting an activation entry
• Interactive systems such as turnstiles, access points, point-of-sale systems, gates, or public terminals that initiate protocol activation
• Batches of activation surfaces intended for deployment across venues, events, offices, campuses, transit systems, public spaces, or digital properties
• Persistent activation endpoints intended for repeated use over time

An activation surface is defined by function, not form.

The protocol does not distinguish between physical and digital surfaces.

Any surface that produces intentional, protocol-valid activation qualifies equally.

Relationship to Lineage Originators

The protocol defines an “originator” as the first activation in a lineage for a given conversion context.

An Infrastructure Originator (IO) is a separate and orthogonal role.

Lineage originators are determined by activation order within a lineage.

IOs are determined by activation-surface origination metadata bound at activation creation time.

A single participant may simultaneously act as:

• an Infrastructure Originator
• a lineage originator
• an intermediate
• a closer
• a generator or salesperson

These roles are independent and evaluated separately.

Eligibility and Origination

Any participant controlling an activation lineage root may originate infrastructure.

Infrastructure origination occurs when:

• A participant creates an activation surface from within a controlled activation context
• The protocol issues a surface identifier (surface_id)
• The surface_id is immutably bound to the creator’s activation (io_activation_id)
• One or more verified activations occur through that surface

Creating an activation surface alone confers no status and no entitlement.

Only downstream verified activations trigger IO attribution.

Attribution Mechanics (Non-Chain)

For each activation:

• At most one io_activation_id may exist
• io_activation_id is assigned only at activation creation time
• IO attribution does not propagate through sharing chains

If an activation is created from:

• an IO-deployed activation surface → io_activation_id is set
• a peer-to-peer share → lineage attribution applies, but IO attribution does not, unless the shared artifact itself was created as an activation surface

Sharing a candle does not constitute infrastructure origination.

IO Share (Economic Rule)

The platform share is fixed at 30 percent of qualifying net-settled revenue.

The Infrastructure Originator share is defined as:

IO share rate γ = 5 percent

The IO share is allocated from the platform share, not from the distribution pool.

For qualifying revenue amount R:

• Platform share = 0.30 × R
• IO share = 0.05 × R (only if a valid io_activation_id exists)
• Net platform retained = 0.25 × R
• Distribution pool and lineage-based allocations are unaffected

If no valid io_activation_id exists, IO share is zero and the platform retains the full 30 percent.

Determination of IO Recipient

For a conversion event attributed to lineage L, rooted at activation a₁:

• If io_activation_id is present on a₁, the IO recipient is that activation
• If no io_activation_id is present, no IO share applies

This determination is deterministic, auditable, and non-discretionary.

Durability and Non-Circumvention

IO attribution is permanent once recorded:

• io_activation_id is written at activation creation time
• It cannot be edited, reassigned, or removed retroactively

Brands, deployers, or partners may not deploy private side agreements, shadow attribution systems, or off-protocol mechanisms that attempt to replicate, suppress, or bypass IO share while using protocol-generated activations.

Any attempt to bypass protocol attribution:

• does not alter on-protocol IO allocation
• does not suppress IO share
• constitutes a violation of protocol terms and access conditions

Prohibited Conduct and Terms

IDDAS is activation infrastructure and is content-agnostic.

Activations, IO attribution, and IO share apply only to qualifying net-settled revenue as defined by this protocol and governed by the Terms and Conditions.

Deployments intended to facilitate illegal goods, illegal services, or prohibited conduct:

• do not produce qualifying revenue
• do not generate IO share
• are subject to enforcement under the platform’s Terms and Conditions

The existence of IO attribution does not create entitlement to payment from non-qualifying or prohibited revenue.

Implementation Note (Non-Normative)

Implementations may expose a single optional control labeled “Deploy Activation Surface”, accessible from a controlled activation context.

The protocol mandates structural outcomes only:

• activation surface issuance
• immutable attribution
• deterministic IO share calculation

Interface design is implementation-specific.

• Brands define business intent
• IDDAS defines and enforces the rules
• Once revenue exists, outcomes are deterministic
• Infrastructure Originators may create activation surfaces and receive a protocol-defined IO share from the platform share.

This separation is intentional. It ensures fairness does not depend on trust, scale does not distort outcomes, and success does not rewrite the rule.

Payouts are derived from allocation outcomes computed under the Allocation Model defined in Section 5.

For each conversion event:

• R is evaluated
• platform allocation and distribution pool D are computed
• contributor allocations are determined deterministically
• payout amounts are recorded as ledger entries

Payout calculation does not imply immediate disbursement and does not alter allocation outcomes.

Payouts are based exclusively on net-settled revenue.

Net-settled revenue is revenue that:

• has cleared payment processing
• is no longer subject to refund, chargeback, or reversal under the applicable settlement window

If revenue does not settle, no payout is finalized.

This requirement applies uniformly across all environments, Brands, and deployments.

Payouts become available for disbursement only after all of the following conditions are satisfied:

• revenue is net-settled
• the minimum payout threshold is met
• all eligibility conditions remain satisfied

The protocol may batch disbursements on a scheduled basis.

Disbursement timing does not affect allocation, eligibility, or recorded outcomes.

A minimum payout threshold applies to each recipient.

Let:

• T = minimum payout threshold

T is defined as:

• T = $5.00

If a calculated payout is below T:

• the amount is not disbursed
• the amount is accrued to the recipient’s balance

Minimum payout thresholds affect only disbursement timing and do not alter allocation or eligibility.

Accrued balances:

• persist across time
• persist across conversion events
• are not forfeited due to inactivity

Accrual affects only when disbursement occurs and does not modify allocation calculations.

A single candle may produce multiple conversion events over time.

For each conversion event:

• allocation is computed independently
• payouts are recorded independently

Revenue from different conversion events is not combined for allocation purposes.

Accrued balances from multiple conversion events may combine to satisfy the minimum payout threshold.

This preserves the distinction between allocation per event and payout per recipient.

Each unit of net-settled revenue is associated with a single conversion event and is allocated exactly once.

The protocol does not permit duplicate payouts for the same revenue.

If multiple conversion events occur, each must correspond to distinct net-settled revenue.

If a conversion event fails to settle:

• the associated allocation is void
• no payout is recorded

If a transaction is invalidated after provisional recording but before disbursement:

• the corresponding ledger entry is reversed or netted
• accrued balances are adjusted accordingly

These corrections reflect the absence of real, net-settled revenue.

They do not imply a refund policy, user-initiated reversal, or discretionary adjustment.

Pay-per-candle pricing supports:

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

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 capacity is exhausted, usage naturally halts until additional credits or prepayment are applied.

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 deployments require a minimum upfront commitment.

The minimum commitment:

• is applied as prepaid usage credits
• is non-refundable
• is immediately usable upon payment

Minimum commitments exist 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 system

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 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
• operate without negotiation or discretionary pricing

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

Candles are priced as individual activation instruments.

Each anchored candle incurs a fixed creation cost.

Pricing is 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 supports:

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

For higher-volume usage, the protocol supports 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

There is no negotiated minimum commitment inside the protocol. Capacity gating is satisfied through prepaid credits when required.

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 the protocol

Credits are deducted automatically as usage occurs.

Unused credits remain available until consumed.

When prepaid credits are exhausted:

• usage continues without interruption
• additional usage is billed automatically under metered pricing

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

Pricing decisions:

• do not affect lineage
• do not affect allocation percentages
• do not affect payout priority

All participants are treated identically under allocation rules regardless of pricing tier, commitment size, or deployment scale.

The pricing model applies universally across all deployments, environments, and scales. Scale is not gated by pricing tiers or negotiated thresholds. Capacity is governed exclusively by activation credits, prepaid balances, and activation burn rate.

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 system
• occurs within the scope of a specific candle and environment
• meets protocol-defined contribution criteria
• is verifiable using system-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:

• system 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 and that participant is both the originator and the closer for the conversion event:

• the participant is treated as both originator and closer
• the participant receives 100 percent of the commission pool C
• No other allocations are created.

If a lineage contains an originator and a closer with no intermediates between them:

• The originator receives 0.30 · C
• The closer receives 0.70 · C

In this case, the fixed intermediate pool (0.15 · C) is reassigned to the originator.

This reassignment is deterministic and does not constitute a discretionary adjustment.

If a lineage contains multiple intermediates:

• the total intermediate allocation remains capped
• intermediate allocations are divided equally
• individual intermediate payouts may be small

Increasing lineage length does not increase the total allocation to intermediates.

This behavior is intentional and reflects diminishing contribution as distance from conversion increases.

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 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 percentages
• payout calculations

are derived mechanically from published rules and recorded events.

There are no discretionary adjustments, overrides, or negotiated outcomes.

The allocation model is published and invariant.

Participants may inspect:

• allocation percentages
• role definitions
• collapse 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

Official records must be maintained in full to support auditability and internal verification, and to support third-party review when authorized.

Sensitive operational and business data, including but not limited to revenue amounts, volumes, and partner performance, is not required to be publicly disclosed.

The public blockchain is used to anchor cryptographic commitments such as hashes, Merkle roots, and protocol rule version identifiers sufficient to enable independent verification.

Independent verification is achieved through mathematical proof of correctness against committed data and published rules, not through public exposure of raw transactional or business data.

Participants may be provided 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, assertions, or interpretations do not affect protocol outcomes.

Transparency concerns what rules apply and how outcomes are computed.

Enforcement concerns how eligibility and verification are implemented.

The protocol discloses rule logic and outcome computation while not requiring disclosure of 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:

• allocation percentages are fixed and deterministic
• lineage is append-only
• conversion events are authoritative
• outcomes derive solely from recorded events
• 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
• platform allocation percentage remains fixed unless explicitly amended
• no discretionary overrides exist

Any amendment that violates these invariants constitutes a new protocol rather than a modification of this one.

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 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 path is:

With the flame off, six rapid taps anywhere open enterprise access. Sealing happens only from that enterprise path.

There are:

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

This action is universal across contexts, devices, and environments.

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

• 1) The candle is lit (burning state)
• 2) The candle is unsealed
• 3) The user performs a continuous 5-second hold directly on the flame

Notes:

• A candle may be sealed immediately upon receipt, or saved and sealed later when reignited.
• An unlit candle cannot be sealed.

Duration

• Hold duration: 5.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 5-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 Section 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
• An enterprise-only 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