A sensing mat, a cloud engine, and a learning loop that gets sharper with every pour.

Klynkz is a three-tier system. At the edge sits the sensing mat, a passive surface under the bottles that reads each one without a person lifting it. In the middle a connectivity layer moves each read off the mat and into the cloud in seconds. In the cloud an AI engine holds the live inventory state, runs detection and prediction, and reconciles every measured pour against the point of sale. The app and the integrations sit on top of that engine, reading from the same state the model writes.

flowchart TB
    subgraph EDGE["Edge: the venue"]
      M["Sensing mat
force-sensing array + RFID antenna"]
      B["Bottles return to the mat
no caps, no scales"]
      B --> M
    end
    subgraph LINK["Connectivity"]
      G["Venue gateway
buffers and forwards reads"]
    end
    subgraph CLOUD["Cloud AI engine"]
      I["Live inventory state"]
      D["Detect: shrinkage and variance"]
      P["Predict: demand and reorder"]
      R["Reconcile against POS"]
      I --> D --> P --> R
    end
    M --> G --> I
    R --> APP["KlynkzLive app
manager surface"]
    R --> POS["8 POS integrations"]

The design point that matters to an investor is the boundary between the patented edge and the data-driven cloud. The mat is what no competitor can legally build. The cloud is what no competitor can quickly retrain. The rest of this page walks each tier in the order data flows through it.

The mat is a passive sensing surface that sits on the back bar under the bottles. Two sensing systems share one surface: a force-sensing resistor array that reads the weight signature of each bottle, and an RFID antenna that reads the tag on each bottle to identify it. The pairing is the invention. Weight alone tells you something changed. The tag tells you which bottle and which brand changed, so the read is objective rather than a human judgment call.

The mat carries a one-time installation fee per venue of roughly $1,000, and Klynkz retains ownership, which means hardware volume scales with venue count rather than with usage. The per-bottle RFID tags are the recurring consumable at $0.35 each. The hardware and the physics that make it work near liquids are both covered by issued US patents, which the moat page walks in full.

A single sensing method has a failure mode. RFID identifies the bottle but does not naturally measure how much is left, and it struggles near liquids because water detunes and absorbs the signal. Weight measures volume but cannot tell two same-weight bottles apart. Klynkz runs them together, so each compensates for the other's blind spot. The result is a read that is both identified and quantified in one motion.

The RFID-near-liquids problem is the one most competitors never solved, and it is the reason no one shipped a reliable bottle-level RFID inventory system before. Klynkz owns the published solution as an issued patent (US 11,715,064), so the hardest part of the read is also the part that is hardest to copy.

Every read flows to a cloud engine that holds one live inventory state per venue and runs four functions continuously against it. The engine is the recurring product, roughly $399 per venue per month, and it is where the data network effect lives: every venue feeds the same model, so accuracy improves for every venue at once rather than one venue at a time.

The engine is multi-tenant by design. Each venue sees only its own inventory and its own numbers, while the learning that improves the underlying model is pooled across the network in aggregate. That separation, private data, shared intelligence, is what lets the data moat compound without exposing one venue's operations to another.

The cloud engine improves through a supervised loop, not a static rule set. Every prediction it makes is checked against what actually happened, and the gap between the two trains a more accurate model. Because the check uses real outcomes, ordered versus consumed versus wasted, the model's accuracy is grounded in venue reality rather than a lab assumption.

flowchart LR
    C["Data capture
every pour logged"] --> P["Prediction
demand, reorder, shrinkage risk"]
    P --> T["Real-world test
ordered vs consumed vs wasted"]
    T --> R["Model refinement
gap trains a sharper model"]
    R --> C
    R --> N["Network-wide
every venue benefits at once"]

1. 01
   Data capture

   Every pour is logged with bottle, brand, volume, time, location, and workstation. The raw signal the model learns from.

2. 02
   Prediction

   The model predicts demand, reorder timing, and shrinkage risk per venue from that venue's own history and the network aggregate.

3. 03
   Real-world test

   Predictions are compared against actuals: what was ordered, what was consumed, what was wasted. Ground truth, not a held-out lab set.

4. 04
   Model refinement

   The gap between prediction and reality trains a more accurate model, and the improvement propagates to every venue on the network.

A read becomes intelligence in roughly six seconds, and the pipeline that carries it is built so a read is never silently lost. At the edge, the mat captures the event and the gateway buffers it. In transit, the event is delivered to the cloud and acknowledged. In the cloud, it is validated, written to the live inventory state, and fed to the model. Each stage hands off explicitly, so a dropped connection delays a read but does not drop it.

The specific buffer depth, retry policy, and end-to-end latency budget are documented for the data room rather than asserted here. [pending source verification against the deployed configuration]

Reconciliation is only as good as the sales data it compares against, so the engine integrates directly with the point of sale. Klynkz reads sales events from eight POS systems and matches them against measured pours. Where a pour was measured but no sale was rung, that gap is the unrecorded loss the system exists to surface. The integration is also a moat: it embeds Klynkz into the same systems the natural strategic acquirers already own.

Each integration normalizes that POS system's sales feed into one internal event shape, so the reconciliation logic is written once and runs against every system. Adding a ninth POS is an adapter, not a rewrite, which keeps the integration surface plannable as the venue base grows.

A bar does not stop pouring because the internet went down, so the system cannot either. The edge is built to keep measuring through an outage. The mat continues to read, the gateway keeps queuing events locally, and the moment the link returns the queue drains in timestamp order. The manager loses live visibility during the outage, not the underlying data, and the inventory state is correct again as soon as connectivity is restored.

The local-buffer retention window and the supported outage duration are scoped in the data room. [pending source verification against the deployed configuration]

The data set is the asset, so protecting it is part of protecting the moat. The architecture keeps each venue's operational data isolated in the multi-tenant engine, encrypts data in transit and at rest, and pools only aggregate learning across the network. A venue's pour-level detail is never exposed to another venue. The security posture is designed to satisfy the diligence of a strategic acquirer, because the buyer is acquiring the data set as much as the hardware.

Specific certifications, encryption standards, and the formal data-governance policy are maintained in the data room rather than asserted on this page. [pending source verification]