Answers.

A dashboard shows what happened and where: sales against plan by store and category, as a chart or table. It leaves the why to the reader. Kelynto is not a BI tool and does not try to be one: there is no free-form analysis, no custom chart builder. It is an enterprise planning intelligence platform, and what it adds is the step after the dashboard: it combines your variance with in-stock, promotions and local signals near each store, proposes a cause with evidence for each material variance, drafts the written explanation, and records whether your planner agreed. Keep your dashboards; they answer different questions. The labeled findings can be exported as CSV and loaded into your BI tool. If your dashboard already tells leadership why, with causes your planners trust, you do not need this.

Possibly, and if your team already produces causal commentary your planners trust, you should not run a pilot with us. We do not know your team, so we will not tell you it is hard for them. What the work involves is specific: matching weather, alerts, events and road work to each store by distance and local week; separating a store-wide traffic effect from a category effect; judging a promotion or event against normal variation so noise is not credited; drafting text whose numbers are checked; and capturing planner verdicts as labels. A fair comparison is time: run a few of your past weeks through Kelynto and set the drafts beside what your team wrote. If it shows nothing new, you have lost very little.

No. Kelynto has no prompt box over your data and is not a chat product. It is an enterprise planning intelligence platform: a rules engine works on your weekly plan, actuals, in-stock, promotions and local signals, and drafts the weekly business review with the evidence behind every cause. A planner edits the draft, confirms or corrects each cause, and publishes it. By default no language model is called at all. An admin can switch one on per workspace, and then it only rewords the week's facts, with every number checked against your data. The assistant on this website is a separate thing: it answers questions about Kelynto from an approved knowledge base and has no access to any workspace.

No. By default Kelynto calls no language model at all. The analysis (variance breakdown, cause attribution, confidence, radar) is a deterministic rules engine with calibrated priors, and the default commentary writer is a template. Both run with no AI service and no outside key. A language model is an optional writer that an admin has to switch on per workspace; if enabled it only rewords the week's aggregated facts, its output is checked number by number, and a failed check falls back to the template. So the honest description is the reverse of a wrapper: the engine does the work, and AI is an optional finishing step for wording. The website assistant you may be talking to is a separate thing from the product's engine.

Excel is fine for the numbers, and Kelynto accepts Excel and CSV files as its input. The difference is the work after the numbers. In a spreadsheet, a planner still has to find out whether a miss was a stockout, a storm, road work, a local event or a competitor opening, usually by checking several other sources, and then write it up. Kelynto does that lookup for every store and category each week, drafts the explanation with the evidence attached, and keeps a record of which causes the planner confirmed. It also keeps versions and an audit trail, which a shared workbook does not. If that part takes your planner under an hour a week, a spreadsheet is the right tool and you should keep it.

No. Kelynto produces no forecast and no plan, and it does not replenish, allocate, price or order. Your planning system keeps doing that work. Kelynto is an enterprise planning intelligence platform: it takes the plan you already have, compares last week's actuals with it by store and category, and explains the difference with the evidence behind every cause. Its forward view, Watch, shows what is coming near your stores and which way each event should push sales. It gives a direction, never an amount, so it is not a forecast either. Kelynto does not change your forecast and makes no claim to improve forecast accuracy. If you need a new forecast engine, this is not it. If your team explains variance to plan by hand every week, this is the part it covers.

A general AI chatbot will write a fluent explanation of any numbers you paste in, but it has no evidence about your stores and nothing checks what it says. Kelynto works differently in four ways. The causes come from a rules engine working on your weekly data and local signals matched to each store, not from a language model. Every number in the draft is checked against your data, and a draft with an unmatched number is discarded. Variance with no supported cause is reported as not yet explained. And the planner's verdict on each cause is recorded and scored, so you can see whether it is earning trust. It is not a chat product: there is no prompt box over your data.

The same answer applies to each of them, because the difference is one of category, not features. Blue Yonder, RELEX, o9, SAP Integrated Business Planning, Oracle's retail planning products and Anaplan are planning and forecasting platforms, by their own public descriptions. Kelynto produces neither. It takes the plan you already have, explains last week's variance to that plan by store and category with evidence, and learns from what your planner confirms or corrects. We do not compare features with any of them and make no claim about what they can or cannot do; your own team knows your implementation best. You keep your planning system. No built connector exists for any of them: Kelynto works from weekly files, which any system able to export them can supply. If your team still writes a Monday variance explanation by hand, the two sit side by side.

They do different jobs. A planning system produces the plan and the forecast, and often the orders that follow. Kelynto starts where that ends: it takes the plan you already have, compares last week's actual sales with it by store and category, and explains the variance with evidence, including causes that sit outside a planning system such as a storm, road work, a local event or a competitor opening. Then it records what your planner confirmed or corrected. It produces no forecast and no plan, and it writes nothing back. You keep your planning system. Kelynto works from weekly files exported from it, so it sits above whichever system, or spreadsheet, produces your plan.

No. Kelynto replaces nothing. It does not forecast, plan, replenish or order, and it does not write back to any system. Your planning system keeps producing the plan; Kelynto reads a weekly export of sales against that plan and explains the variance. Nothing is migrated and nothing in your current process is switched off, so if it does not help, you stop and nothing has changed. The only thing it aims to take over is the manual work of finding out why a store or category missed plan and writing that up for leadership, and even there a planner still edits and publishes every review.

It may be, in part, and you should check. Planning suites are built to produce the plan and forecast, and many include exception reports, alerts or analytics on forecast error. We make no claim about what any vendor's product can or cannot do. The practical test is simple: does a planner on your team still spend time each Monday working out why stores missed plan, looking at weather, local events, road work or store issues, and writing a paragraph for leadership? If yes, that work is what Kelynto covers: a drafted explanation with evidence, a planner's verdict on each cause, and a scorecard of how useful that was. If your current system already gives leadership the why, you do not need this. You keep your planning system either way.

There is no accuracy figure on real retailer data, so we will not quote one. What exists: automated tests on synthetic data in which known effects were planted, checking that planted promotions, weather, stockouts, road work and a competitor opening are found, and that a week of pure noise produces no causal finding. That proves the logic behaves as designed; it does not prove accuracy on your business. The demonstration workspace is synthetic too, and its numbers are not results. The only honest measure is your own planners' verdicts: the cause hit rate and edit rate on your weeks. A practical first test is to run a few of your past weeks and set each draft beside what your team actually wrote.

The engine can credit these causes when the evidence supports them: inventory availability (stockouts), severe weather, storm stock-up, road work, competitor opening, competitor closing, store operations (remodels, closures, outages), local events, promotions, and other local signals you supply. Weather, weather alerts, events and road work can be pulled from outside sources; competitor and store-operations signals come from a file you send. When a planner corrects a finding they can also label it as a pricing change, a plan or forecast error, or a data issue, but the engine does not detect those three by itself today. It does not model cannibalisation, halo, price elasticity or assortment changes. Anything outside the list shows up as not yet explained.

By default a deterministic template writer produces the draft. It needs no outside AI service, gives the same text for the same facts, and is always available, so a review never fails for lack of a model. An AI writer is optional: an admin must switch it on for the workspace and choose a provider (Anthropic, OpenAI or Azure OpenAI) that the deployment holds a key for. Either writer receives only the week's aggregated facts, and an AI draft is checked number by number against those facts; if one number does not match, the draft is discarded and the template version is used. The AI writer has not yet been exercised end to end with a live provider, so treat it as built but unproven.

Confidence is a calculated number, not a feeling. For each cause it multiplies two things: how often planners have confirmed that type of cause (a starting prior per cause type, updated from your planners' confirmations and rejections), and how well this week's evidence fits (signal strength, whether the size of the effect is plausible for that cause, and how far the result stands clear of normal variation). The formula is confidence = posterior x (0.45 + 0.55 x fit), capped below 1. Scores of 0.62 and above are shown as high, 0.42 and above as medium, the rest as low, and the band decides how firmly the commentary words the claim. It is a ranking aid for the planner, not a probability validated on real retailer data.

Currency is a label per workspace, not a conversion. Amounts are loaded exactly as you send them and printed with the mark of your currency setting: the dollar sign for USD and CAD, the pound and euro signs for GBP and EUR, and any other three-letter code as a prefix. Numbers are written in English format. If the optional AI writer produces an amount with a different currency symbol, the draft is rejected. Two limits: there is one currency per workspace, so a chain reporting in two currencies would need to send one of them converted, and changing the setting later does not restate reviews already written. Currency symbols and thousands separators in your files are read correctly on upload.

No. Harborview Markets is a made-up retailer: 36 stores and 26 weeks of synthetic sales, plan, in-stock and signals produced by a generator. The shocks in it were written by that generator, so the engine finding them shows that the pipeline works, not that it is accurate. Its history includes simulated planner reviews, marked as such in the audit log, so the scorecard has something to display. Screenshots on the site come from this workspace. None of its numbers are results and none should be quoted as such. No real retailer's data, name or logo appears anywhere in the product or the site, because no retailer has used it yet.

Yes. The draft is the first version; every planner save creates a new version, and the app keeps the history, can show a planner's text against the original draft, and can restore an earlier version. If two people save at once, the second gets a clear conflict message instead of silently overwriting. An edit in progress is held in the browser tab, so it survives a sign-in that expires mid-edit and is offered back afterwards. The difference between the draft and the planner's final text is measured word by word as the edit rate: 0 means the draft was sent unchanged, 1 means it was rewritten. That number is one of the four scorecard measures.

Attribution is a rules-based engine, not a trained model and not a language model. For each store and category it separates a store-wide effect (most categories moving together suggests traffic) from the category's own residual. Stockouts are measured directly from the drop in in-stock against the store's own recent level. A cause that covers many stores, such as a promotion, a local event or storm stock-up, is judged on the net of everything it covers against the ordinary spread between stores that week, and it must clear a statistical bar before it is credited. A promotion at ten stores is compared with the same category at the stores without it. If the bar is not met, nothing is credited. Every finding carries its evidence, and a planner confirms or corrects it.

Four steps, repeated every week.

Explain: why last week's sales missed or beat plan, by region, category and store, with the evidence for each cause. What cannot be explained is reported as not yet explained.

Watch: Forward Radar lists local signals near your stores in the coming weeks (road work, events, severe weather, competitor openings) with an expected direction, up or down. No sales figures are forecast.

Act: the planner edits the draft, confirms, rejects or corrects each cause, marks radar items and publishes the review.

Score: a scorecard built only from what planners did and what sales then did: draft edit rate, cause hit rate, radar direction accuracy and whether planners would use it every week.

The weekly review can be copied with formatting or as plain text, downloaded as Markdown, HTML (suitable for email) or plain text, and printed or saved as PDF through the browser's print view. There is no direct PowerPoint or Word export; copy with formatting is the route into a slide or document. Analysts and admins can also export two datasets as CSV: the labeled findings (cause, amount, planner verdict) and the radar outcomes (expected against observed direction). Those can be loaded into your own BI tool. CSV exports neutralise cells that a spreadsheet would run as a formula. Admins can read the audit log in the app. You own all of this data.

Three honest limits. First, it gives direction only: up or down, never an amount. Dollar forecasts would be unvalidated; direction can be checked every week. Second, the horizon is short: three weeks by default, and a workspace setting allows 1 to 8 weeks. Weather inside that window is only as good as the public forecast. Third, it has no accuracy record. The target is 75 percent of flagged stores moving the way the radar said, and that is a pilot target, not a result. Two practical notes: the outside signal sources have not yet been exercised from a live deployment, and for a chain near 2,000 stores the per-store lookups are slow enough that signals should be refreshed as a separate job. It is not a forecast and does not feed one.

Forward Radar is a list of things coming near your stores that are likely to move demand: road work, large local events, severe weather, competitor openings and closings, store operations and other signals you supply. Each item names the stores affected, the week, the expected direction (up or down) and an impact score used for ranking. Lines read like: 8 stores, road work beginning next week. Planners mark each item as new to me, already knew or not relevant. Once the week has happened, the radar checks itself: did the flagged stores move the way it said? That result is the radar direction accuracy on the scorecard. It needs store coordinates, and it is only as good as the signal sources switched on.

Every number in a draft is parsed (money, percentages, counts, dates, scale words and numbers written as words) and must match a number in the week's facts within the rounding its own format implies. One unmatched number, or an amount in the wrong currency symbol, fails the draft; the deterministic template writer is used instead and the reason is shown on the run. The limits are stated plainly: the guard checks numbers and currency symbols. It does not check direction words such as above or below, names, or fractions written as words such as half or doubled. That is one reason a planner reads and publishes every review. The causes themselves never come from a language model; they come from the rules engine.

Yes, always. Kelynto drafts; a planner decides. Each finding can be confirmed, rejected or corrected to a different cause, and the commentary is only published when a user with the planner, analyst or admin role publishes it. Nothing is sent to leadership automatically, and a published review can be reopened. Those verdicts are recorded as labels: they feed the scorecard, adjust how confident the engine is in each type of cause for your business, and can be exported by you. Every edit, label and publish action is written to the audit log with the person who did it. If your planners reject most causes, the scorecard will show it plainly, which is the point.

It will be wrong sometimes, and the product is built around that. A cause in the draft is a candidate with its evidence and a confidence band, not a verdict. The planner rejects or corrects it before anything is published, and nothing reaches leadership without a person publishing it. Each rejection lowers the confidence of that cause type for your business and shows up in the cause hit rate, so a pattern of wrong causes is visible within weeks, not hidden. Low-confidence claims are worded cautiously. Variance with no supported cause is left as not yet explained. Known gap: the number check does not verify direction words or names. The planner remains the author of the review; Kelynto is the first draft.

It learns in a narrow, transparent way. Each confirmation or rejection updates the prior for that cause type in your workspace (a beta-binomial update), which raises or lowers the confidence shown next time. Edits feed the edit rate, radar verdicts feed the novelty rate, and pulse answers feed time saved and the would-use score. There is no trained model behind attribution today: it is rules with calibrated priors, chosen because there is no ground truth until planners label real weeks. The labels are also exportable as a dataset (signal, business impact, human-confirmed cause, outcome) that belongs to you. Kelynto does not use your data to train any model. We make no claim about how quickly results improve; no retailer has run it yet.

The closed week's data arrives by upload or scheduled export. A scheduler then produces the review; the default is Monday 06:00 in your time zone, and you set the day and hour to fall after your data is complete. When the planner opens Review, the draft is already written: the headline variance, the drivers by region, category and store, each cause with its evidence and confidence, and a radar preview. The planner edits the wording, confirms, rejects or corrects each cause, marks radar items as new, already known or not relevant, answers two short pulse questions (minutes spent, would you use this every week) and publishes. The review can then be copied, downloaded or printed. We have no measured figure for planner time yet; the pulse question exists to measure it on your own weeks.

Store and category numbers wobble every week for no reason. The noise guard stops that wobble being reported as a finding. A store and category move with no known cause is listed as not yet explained only if it clears your two materiality bars (a percentage and a minimum amount) and is also larger than a multiple of that category's ordinary spread between stores that week. The default multiple is 3; lowering it shows more cells, and 0 switches the guard off. The spread is measured from your own data each week, so it needs no tuning to start. In local testing on data with no real effect, a fixed 4 percent bar flagged about one cell in fifteen; with the guard, a handful. Named causes must pass a separate statistical gate.

Four roles. Viewer reads published and in-progress reviews; it suits leadership and store operations. Planner edits the commentary, confirms or corrects causes and publishes. Analyst does everything a planner can, plus data uploads, re-runs and dataset exports. Admin does everything, plus users, workspace settings and the audit log. Permissions are checked on every API route, not only hidden in the interface. With single sign-on, roles come from your identity provider, so removing a role there removes access on the user's next request. There are no custom roles and no per-region or per-category permissions: everyone in a workspace sees the whole workspace.

Each measure stays at insufficient data until it has enough evidence: 10 reviewed causes for the hit rate, 10 stores that moved materially for radar direction accuracy, 3 pulse answers for would-use, and 2 reviews with planner edits for the edit rate (which is then the median of up to the last four). The overall verdict is shown only when at least two measures have enough data, and it reads on track only if every judged measure meets its target. The same store, signal and week flagged by several runs counts once. Supporting figures are shown beside the four: radar precision, how often radar items were new to the planner, minutes saved against your stated baseline, and hit rate by cause type.

Four measures, each with a default target that you can change per workspace.

Draft edit rate: how much of the draft the planner changed, median of the last four reviews. Target 20 percent or less.

Cause hit rate: findings planners confirmed out of those they reviewed. Target 60 percent or more.

Radar direction accuracy: flagged stores that moved the way the radar said, among those that moved materially. Target 75 percent or more.

Would use every week: the planner's weekly answer on a 1 to 5 scale. Target 4 or higher.

Everything is computed from what planners actually did and what sales then did, never from synthetic data. These are targets for a pilot, not results: no retailer has produced a scorecard yet.

We do not have a measured figure, and we will not invent one. No retailer has run Kelynto yet, so any hours saved or return on investment number would be a guess. What the product does is measure it for you: at the start you state how long the Monday review takes today, each week the planner records the minutes spent, and the scorecard shows minutes saved per week beside the four main measures. That gives you your own number after a few weeks instead of ours. If the honest baseline is under an hour a week, this is probably not worth your time. A useful first step is to tell us who writes the review today and how long it takes.

Both are workspace settings. The fiscal week can start on any day; files can carry a week start, a week ending date or daily dates, and daily rows are summed into your fiscal weeks. Set the week start before the first load, because rows are aligned as they are read. Signals are matched to the stores' local week: a week runs from local midnight to local midnight in your time zone, including across daylight-saving changes, so a Sunday night event counts in the week it happened. The limit: one time zone per workspace, so a chain spanning several zones should choose the zone most of its stores are in. Reviews are weekly; there is no fiscal period or 4-5-4 month roll-up today.

It says so. Variance with no supported cause is reported as not yet explained, never assigned to the nearest plausible story. A category that moved across the chain with no cause on file appears as a single finding, for example produce above plan across most stores, not yet explained. If a promotion or event was on file but what it covers did not move beyond normal variation, the review says that too. The engine holds an invariant that tests enforce: explained plus unexplained plus noise always equals the variance. How much is unexplained depends on your data and signals; there is no real-retailer figure to quote. Unexplained items are useful: each is a missing signal, a threshold to tune or a cause the planner already knows and can label.

Variance is actual sales minus plan sales, computed for every store and category you send and rolled up to category, region and total. The rollups reconcile to the total, and that is enforced by tests. In the app the planner can view the week by region, by category or by store, and open a single store to see its categories and the signals near it. A week in which gains and misses nearly cancel is described in amounts above and below plan instead of shares, because a share of a near-zero net is meaningless. The grain is store by week by category: item-level data is not required, and item-level explanations are not produced.

Kelynto is an enterprise planning intelligence platform for retail planning organizations. It explains why actuals differed from plan, with the evidence behind every cause, watches for what is coming near your stores, records what planners did about it, and scores whether its explanations proved useful. It works alongside your planning system.

In practice, it drafts the weekly business review that a planning team otherwise assembles by hand, and where the evidence does not support a cause it reports the variance as unexplained instead of guessing. It is not a forecasting tool, a BI tool, a chatbot or a replacement for a planning system. Honest status: Kelynto is built and tested locally on synthetic data, no retailer has run it yet, and the hosted service is not running.

It does not forecast demand, build the plan, replenish, allocate, price or order. It is not a BI or dashboard tool, not a supply-chain suite, and not a chatbot you ask questions of your data. It does not write back to any planning system or ERP. It does not need or hold transactions, baskets, shopper, payment or employee data. Radar gives direction, never amounts. Attribution is rules with calibrated priors, not a trained model. The job is narrow on purpose: explain last week's variance to the plan you already have, show what is coming near stores, capture what the planner confirmed, and score whether that was useful. If you need a new forecast engine, keep looking; if your team writes a Monday review by hand, this is the part it covers.

Kelynto drafts the Monday business review for a retail planning team. Each week it takes sales against plan by store and category, plus in-stock, promotions and local signals, works out where the variance came from, and drafts the commentary with the evidence behind each cause. The planner edits the draft, confirms or corrects each cause, and publishes. It also shows what is coming near your stores in the next few weeks, and keeps a scorecard of whether its explanations are proving useful. It sits above the planning system you already use and replaces none of it. Honest status: it is built and tested locally on synthetic data, and no retailer has run it yet. The quickest way to judge it is a 20-minute conversation about your own Monday review.

It is built for regional retailers whose planning team owes leadership a weekly explanation of sales against plan. The people who use it are demand planners, merchandise planners and analysts; the people who read it are directors and vice presidents in planning, merchandising, supply chain and store operations. The fit is best where a plan exists by store and category, where a named person writes commentary every week, and where the causes sit outside the planning system: stockouts, weather, local events, road work, competitor openings. The design centre is a chain of roughly 50 to 500 locations. Larger chains are a conversation: the only scale figures we have are local tests at 500 and 2,000 stores on synthetic data. If nobody writes a weekly review today, it is probably not for you.

A readout of the four measures and a decision. The pilot runbook reads the results this way: all four on track means the product fits this team, and the next step is to continue and automate the data feed. A high edit rate with a good hit rate means the causes are right and the wording is not, so the writer is tuned. A low hit rate means causes are wrong or missing: read the corrections before continuing. A low would-use score despite good accuracy means the pain is not strong enough here, and we would say so. Commercial terms for continuing are not finalised and would be agreed in a conversation. If you stop, you keep your exports and your data is deleted on the agreed date.

Pricing is not finalised. It will depend on deployment model, number of locations and pilot scope. The fastest way to get a number for your situation is a 20-minute conversation.

That applies to pilots as well as to a subscription: there is no published pilot fee and no list price, and the assistant cannot quote, estimate or negotiate one. What can be said is what a pilot involves on your side: weekly files, four named people and a planner's attention each week. To get terms for your situation, book 20 minutes at https://calendly.com/kelynto or write to marc@kelynto.com.

Four named people. A sponsor who signs the pilot, names the others and receives the scorecard. An IT contact who registers the application in your identity provider, assigns roles and handles the security review. A data contact, usually an analyst, who produces the files, reads the validation reports and owns the weekly export. And a planner who reviews each week's draft, confirms or corrects the causes and publishes. The planner's weekly part is the same work they do today, starting from a draft; we have no measured figure for how long it takes. It is not zero effort on your side: a file has to arrive every week and a planner has to engage. Nothing in your current process is switched off during a pilot.

In two ways, both on your data. Before going live, a backtest: four to eight of your past weeks are run and each draft is compared with the commentary your team actually wrote. It is the fastest read on fit. Then the live weeks feed a scorecard that is computed only from what your planner did and what sales then did: how much of the draft they changed, which causes they confirmed, whether flagged stores moved the way the radar said, and whether they would use it every week. Each measure shows insufficient data until it has a minimum sample. Beyond the numbers, two things are worth watching: whether the planner is editing or rewriting, and whether a radar item marked new to me then moved sales.

Offboarding is a documented procedure. You agree an end date and a deletion date in writing. Before the end date you can export your labeled findings, radar outcomes, published commentary and audit log. On the end date access is blocked and the data kept, which can be undone. On the deletion date one operator command deletes the workspace and every row it owns in a single transaction, verifies nothing is left, and prints a deletion record that we send you. Two things remain for a while and we say so: database backups hold the deleted rows until backup retention passes (35 days in the production settings), and logs hold request metadata, never sales figures, until log retention passes. The exit terms themselves belong in the pilot agreement. The deletion procedure was rehearsed locally, not yet on a live service.

Book a 20-minute conversation with the founder at https://calendly.com/kelynto, or write to marc@kelynto.com. It is a working conversation, not a pitch: how your Monday review gets written today, who writes it, what data you plan with, and whether a pilot would answer a real question for you. Useful things to bring: your number of stores, the planning system or spreadsheet your plan comes from, whether you plan at store and category level, and one past commentary if you can share it. If it looks like a fit, the next steps are a short pilot agreement, the data and identity checklist, and a backtest on your past weeks. If it is not a fit, we will say so.

Two routes exist in the product, and neither is set up yet. First, a shared sign-in provider: Kelynto would run one identity provider for customers who cannot register an application in their own directory for a pilot; a signed claim in the token selects your workspace and roles are stored on the account in Kelynto. Your users' credentials and multi-factor settings would then be held by that provider, which becomes a subprocessor. Second, the product's own sign-in by emailed single-use link or code, with no password and one factor only; it is off until the operator switches it on. In both, revoking a user means deactivating the account in Admin, and you can move to your own directory later with accounts keeping their history. Status: both code paths exist and were rehearsed locally with a mock provider and a test mail server; no shared provider has been chosen and no mail service is set up.

In order: a kickoff call to name the people and agree the fiscal week start, time zone and data timing. A Kelynto operator creates your workspace. Your IT contact registers the application in your identity provider and assigns roles, or you use the shared sign-in provider if you have no single sign-on. Sign-in is proven on a call with an admin, a second role and a user without a role. Your data contact exports the files; they are loaded and every validation report is read together. A readiness check runs, the first week is run by hand and read by the operator, and your planner is walked through the first draft. Then the weekly export and schedule are switched on. These steps were rehearsed end to end with a synthetic retailer; no real customer has been onboarded yet.

A pilot answers one question on your own data: would this planning team use Kelynto every Monday? It has two parts. First, a backtest: we load your history, run four to eight past weeks and set each draft beside the commentary your team actually wrote, so you see the fit before anyone changes how they work. Then about six live weeks, in which the review is produced each week and one planner edits it, confirms or corrects each cause, marks radar items and answers two pulse questions. It ends with a readout of four scorecard measures agreed at the start. Honest status: no pilot has been run yet. You would be among the first, and the scorecard is there so the result is measured in the open.

Four things. A store list with store code and region, and coordinates for all or nearly all stores. Weekly sales and plan by store and category: 26 weeks or more of history, then the closed week every week. In-stock by store, week and category if you have it, at least nine weeks, or an acceptance that stockouts will not be attributed. Optionally promotions and local signals you know about. We also ask for four to eight weeks of the commentary your team already wrote, for the backtest, and for two facts before the first load: the day your fiscal week starts and the time zone most stores are in. CSV or Excel, your own column names. Aggregates only: no transaction, shopper, payment or employee data.

No. The pilot runbook allows the first weeks to be run by hand: you send the week's files, a Kelynto operator runs the week, reads the draft and evidence, and sends the exported commentary by email. Your planner replies with edits and verdicts on each cause, and the operator enters them on the planner's behalf. The edit rate and hit rate are the same either way. This keeps the pilot moving while your IT team registers the application in your identity provider, and it can be a smaller thing for IT to review at the start. The trade-off is that in this mode Kelynto staff handle your files and enter your planner's feedback, so it should be covered in the pilot agreement.

Four default targets, agreed before the first live week and adjustable for your workspace. Draft edit rate at or below 20 percent (median of the last four reviews). Cause hit rate at or above 60 percent (at least 10 reviewed findings). Radar direction accuracy at or above 75 percent (at least 10 stores that moved). Would use every week at 4 of 5 or higher (at least 3 answers). These are evaluation criteria, not a performance guarantee, and none has been met by a real retailer yet because no pilot has run. If your own bar is different, for example a specific question leadership keeps asking, say so at the start so it can be discussed for the pilot agreement.

Planning estimates, stated as such: no customer has gone through it yet. From a signed pilot to the first scheduled Monday review is about two weeks when registering the application in your identity provider takes a week. It can be as little as three or four working days on the shared sign-in provider with clean files. The step that usually sets the pace is your own change process for registering an application, which we do not control; the first data export is estimated at two to seven days. The pilot itself then runs about six weeks of live reviews. Nothing requires your planner to sign in on day one: if sign-in is the last thing outstanding, the weeks can be run and the commentary sent by email meanwhile.

Yes. In the web app a file is checked and shown as a preview before anything is loaded. Column names the data contract knows are mapped by themselves. For any other column the preview proposes a field from the name and the values, with a confidence, and you confirm or change each one; nothing is applied until someone confirms it, and a confirmed mapping is remembered for next week's file. Repairs with only one possible reading are applied and reported: stray spaces, currency symbols and thousands separators, mixed date formats, store codes that lost their leading zeros. Some things are never guessed, such as whether 03/04 is the third of April or the fourth of March: you are asked once. Unknown stores, new category names and weeks that already hold data are shown with a choice. The product is not yet hosted, so today this is seen in a walkthrough.

Usually not. The validator recognises many common names for each field, for example Store Nbr, Dept, Net Sales, Forecast, LY Sales and OSA, and the upload report shows exactly how each of your columns was mapped. It also reads real-world number formats: currency symbols, thousands separators, negatives in brackets and percentages, and it detects whether in-stock is on a 0 to 1 or 0 to 100 scale. If a required field is not found under any known name, the file is rejected and the report lists the columns it did not recognise; one of them is usually the missing field under another name. In the web app the upload preview then proposes which of your columns is which field; you confirm it once and it is remembered for the next file. Through the upload API alone, the fix is to rename the column. The full list of accepted names is shown on the Data page.

CSV and Excel .xlsx. Delimited files may use comma, semicolon, tab or pipe, and the separator is detected. The encodings exports usually come in are read: UTF-8 with or without a byte order mark, Windows-1252, and UTF-16 (what Excel saves as Unicode Text). In a workbook with several sheets, the sheet whose columns match the dataset is read; when that cannot be told, you are asked which. Not supported: legacy .xls, password-protected workbooks, Parquet, JSON, XML, EDI and fixed-width files; a file that cannot be read is refused with what to change. Large files should be sent as CSV: a CSV is parsed from disk in blocks, while an Excel workbook is unpacked in memory and loads at roughly half the speed in local tests. The default upload limit is 50 MB per file; a larger history can be split by date range, since uploads update in place.

The working grain is store by week by category. Daily rows are accepted and summed into your fiscal weeks. Rows below category level, such as a file split by sub-department or item, are added up to the category in the file, provided each row carries the store, week and category; the report warns how many rows were combined. What you call a category is your choice: department, category or subclass all work, as long as sales and plan use the same level. Explanations are produced at that level and no lower, so item-level questions (which SKU was out of stock) are outside what it answers. Sending aggregates is also the lighter option for your security review.

Some mess is handled; some has to be fixed at the source. Handled: your own column names, currency symbols and separators, blank lines, a title above the header row, mixed encodings, week-ending or daily dates, and placeholder dates (flagged as row errors). Category and region names that differ only in capitals, spaces or punctuation are loaded as one name, listed in the report. A row that repeats an earlier row exactly is counted once. Rows for the same store, week and category that differ are added together, with a warning, which is right for files split by sub-department and wrong if the export has a fault. Not handled: store codes that do not match your stores file (those rows are skipped), a missing plan, and files where more than one row in five has an error (rejected outright). A dry run validates every file and writes nothing, so the practical step is to send one export and read the report.

Technically one week of sales with plan is enough to write a review. Stockout attribution compares each store and category's in-stock with its typical level over the eight weeks before, so nine weeks of in-stock gives the full baseline. For a pilot we ask for 26 weeks or more of sales and plan. That lets past weeks be run and set beside the commentary your team actually wrote, and gives radar outcomes something to be scored against. You do not need years of history, because nothing is being trained and no forecast is being fitted. If you have less than 26 weeks at store and category level, it is still worth a conversation about what a shorter backtest can show.

Then be cautious, because the product explains variance to plan at store and category level, and the sales file requires a plan value on each row. If no plan exists at that level, there is no variance to explain at that level. Prior-year sales is an accepted optional column, but running the whole review against last year instead of a plan is not a documented mode, so we will not claim it works. Two honest options: start with the part of the business where a store and category plan does exist, or talk to us about how your plan is spread to stores today, since many teams have an allocated plan they do not think of as one. It is better to find this out in a 20-minute conversation than in week two.

No shopper, payment, transaction, basket or employee HR data is needed, and the data contract has no field for any of it. Please do not send it. What Kelynto holds is confidential business data, not consumer data: weekly sales and plan by store and category, in-stock rates, promotions, the store list with coordinates, and the commentary and labels your users write. The only personal data is business contact data about your users: work email, display name, role and last sign-in time, taken from your identity provider. No cardholder data, health information or government identifiers are processed, which is why frameworks specific to those data types are not in scope for the data itself.

Yes, through the optional signals file. Each row is one local fact: a type (event, weather, road work, competitor opening, competitor closing, store operations such as a remodel, closure or outage, or other), a title, a start time, and either a store code or coordinates. You can add an end time, severity, expected attendance, an expected direction and the categories affected. Those signals are then treated like the automatic ones: matched to stores by distance and week, considered as causes in the review, and shown on the radar when they are in the coming weeks. Today signals arrive by file upload or the upload API; there is no form in the app for a planner to type one in.

You do. The security overview states that the labeled dataset stays in your workspace and is exportable by you, and the pilot runbook states that the customer owns the exported findings and radar outcomes. Analysts and admins can export the labeled findings and radar outcomes as CSV and each review as a document at any time. Kelynto does not use your data to train any model, and workspaces are isolated from each other in the application and in the database, so one customer's data and labels are not visible to another. The precise ownership, licence and confidentiality wording belongs in your agreement; there is an outline of a pilot agreement, to be finalised with counsel, and that is the place to check it.

Two files are enough for a first review. Stores: one row per store with a store code and region; latitude and longitude are strongly recommended, because without them no weather, event or road-work signal can be matched. Sales: one row per store, week and category with actual sales and plan sales. Three optional files add depth: in-stock percentage by store, week and category (this is what makes stockout attribution possible, and is the single most valuable addition), promotions by week and category, and local signals only you know, such as a competitor opening or a remodel. Everything is weekly aggregates. Item-level, transaction, basket, shopper, payment and employee data are not needed and should not be sent.

Store coordinates and dates, nothing else. Open-Meteo receives latitude and longitude rounded to four decimals and a date range. The United States National Weather Service receives a coordinate pair per store, with a contact in the request header that you set to your own in a Customer Environment. PredictHQ, only if enabled, receives coordinates, a radius and a date range. Road-work feeds receive nothing: the feed is downloaded and matched to stores inside the deployment. No store names, sales, plan, in-stock, commentary or user details are sent to any of them. A full set of coordinates does reveal your store footprint to those services, so each source can be switched off per workspace, and one deployment-level setting forbids all of them for every workspace, whatever its administrators choose. Local facts can then be loaded as a signals file instead.

Four adapters exist. Open-Meteo for weather and the US National Weather Service for alerts are on by default. PredictHQ for local events is off by default and needs a PredictHQ key in the deployment, which is a commercial service you or we would have to license. State road-work feeds in the WZDx format are used when an admin adds the feed addresses, up to 20. Each source can be switched off per workspace, and one failing never blocks the weekly run. There is no foot traffic, mobile location, social media, competitor pricing or syndicated market data. An honest caveat: these adapters are covered by automated tests, but they have not yet been exercised against the live services from a deployment, and the alert source covers the United States only.

Every file gets a report with one of three outcomes. Accepted: every row loaded. Partial: some rows were skipped (unreadable values, or store codes not in your stores file) and the rest loaded; the report lists the problems by row number. Rejected: a required column is missing, more than 20 percent of rows have an error, no row could be loaded, or a sales or in-stock file arrived before any store was loaded; nothing is loaded, so a broken export cannot overwrite good data. The report also shows how columns were mapped, what was assumed, and a summary of every problem with its count. Uploads are idempotent: a corrected file for the same weeks updates in place.

No connector exists today, so this would be scoped implementation work, not something to switch on. In most cases a connector is not needed: the requirement is four weekly files at most, and a scheduled export from your planning system or warehouse to the upload API covers it. That work is usually a query, a schedule and a token from your identity provider, owned by your data contact, with the validator's report to confirm each load. A true connector, one that reads your system's own interfaces, would mean agreeing access, credentials, data mapping, error handling and who maintains it when your system is upgraded. We would rather start with the export, learn what your data looks like, and only then discuss whether a connector earns its cost.

No. Kelynto does not connect to Snowflake, BigQuery, Databricks, Synapse or any other warehouse, and it holds no credentials to your systems. Data arrives as files that your side sends: a scheduled job queries your warehouse, writes the weekly files in the documented contract and posts them to the upload API. For many IT teams that is the simpler pattern to approve, because data is pushed out by a job you control and nothing reaches in. The files are weekly aggregates by store and category, typically small. If a direct connection is a firm requirement, say so in a conversation so it is recorded as a real need; we will not promise it here.

No built integration exists with any of them, and we will not imply one. Kelynto is independent of the planning system: it reads weekly files in a documented contract, so it works alongside any system that can export weekly sales and plan by store and category. That includes a spreadsheet. In practice your team schedules an export from the planning system or the warehouse behind it and posts the files to the upload API. Building and scheduling that export is implementation work on your side, with our help on the file format; the validator recognises many common column names, so the export rarely needs reshaping. Nothing is written back to the planning system.

It works alongside SAP, and there is no SAP connector. No integration with SAP IBP, S/4HANA, BW or any other SAP product has been built, and Kelynto holds no SAP certification of any kind. What it needs is a weekly export of sales against plan by store and category, a store list, and optionally in-stock and promotions. Any system that can produce those files can feed it. The usual pattern is a scheduled job on your side that writes the files and posts them to the upload API using a token from your identity provider. Setting that export up is implementation work done with your data contact, not a product feature. A first evaluation can start with files exported by hand.

The pattern is a scheduled export on your side. A job in your scheduler or data platform writes the closed week's files and posts each one to the upload API with a token from your identity provider for an identity holding the analyst role. No agent is installed and Kelynto does not pull from your systems. Schedule it to finish before the weekly review runs; if the data is late, the review is retried about hourly, four attempts in total by default. Until the job exists, an analyst can upload the files in the app each week, which is fine for an evaluation. There is no SFTP drop, email intake or message queue today: HTTPS upload, the app, or an operator-run first load are the three paths.

Plainly: there are no built connectors to any planning suite, ERP or data warehouse. Input is files in a documented contract: stores, weekly sales against plan, and optionally in-stock, promotions and local signals, as CSV or Excel. There are three ways to deliver them: upload in the app's Data page, send them to the upload API (one HTTP request per file, which is how a scheduled weekly export works), or have a Kelynto operator load a directory at the command line for the first load. All three go through the same validator and produce the same report. Nothing is installed on your side. Outbound, the product can pull weather, weather alerts, events and road-work feeds. It writes nothing back to your systems.

Yes. Each dataset has an upload endpoint: POST /api/v1/data/uploads/{kind}, where kind is stores, sales, inventory, promotions or signals, with the file as a multipart field. The caller needs an access token for a user or service identity that holds the analyst or admin role in your identity provider; Kelynto issues no API keys of its own. The response is the same validation report the app shows: rows loaded, rows skipped, how each column was mapped and what was assumed. Uploads are idempotent, so sending the same week again or a corrected file updates in place. The default size limit is 50 MB per file, and uploads are rate limited to 20 a minute per user. The token, role and limits are checked before the file body is read.

Available through enterprise implementation. A Terraform module for AWS (ECS on Fargate, RDS for PostgreSQL) is written and checked statically; it has never been planned or applied against an AWS account. It has the same shape as the Azure kit: Secrets Manager, an Application Load Balancer with AWS WAF, CloudWatch logs and alarms, your own VPC and your own KMS key if you want them, and scripts for preflight, deploy, validate, upgrade and rollback. What "checked statically" means here: the module was checked against the AWS provider's published schema and with a policy scanner, and the scripts ran against stand-ins. Terraform itself has not validated it, and nothing has started in an AWS account, so a first install would be the validation run and fixes should be expected. If AWS is your requirement, say so early in a conversation.

Available through enterprise implementation. The deployment kit for Azure is built and validated statically; it has not yet been deployed to a live subscription. What the kit is: Bicep templates for a single-tenant install in your own subscription (Container Apps for the API, web app and scheduler, PostgreSQL Flexible Server on a private network, Key Vault, Log Analytics, optional Front Door), signing in with your own directory, plus scripts for preflight, deploy, validation, upgrade, rollback and uninstall. A private shape adds your existing virtual network, private endpoints, internal ingress and a database key you hold. The templates compile and lint, the scripts ran against stand-ins, and the same container stack ran locally in production mode with a full onboarding rehearsal. The first real deployment would be the validation run, so small fixes should be expected. You own the subscription, network, keys and backups.

Kelynto can run inside your own cloud account. In that model your sales, plan and in-stock data, your store list and your users' details are stored and processed in your environment and are not sent to Kelynto. The software does not call home.

Your data does not have to leave your environment. By default Kelynto looks up weather for your stores by sending their coordinates (no names, no sales) to two public weather services. You can switch that off, for one workspace or for the whole deployment with a setting no workspace administrator can change. With it off and the standard template writer, the only outbound connection is to your own identity provider, to download its public signing keys.

Available through enterprise implementation. The deployment kit for Azure is built and validated statically; it has not yet been deployed to a live subscription.

No. There are no templates and no testing for Google Cloud; what exists is a one-page mapping of the components to Google Cloud services, written as a design statement that nobody has tried. The deployment kits are for Azure (built, validated statically) and AWS (a Terraform module checked statically only). The application itself is three containers and a PostgreSQL database, and a Docker Compose path for any container host with your own PostgreSQL server was run locally, so nothing in the application code depends on a particular cloud. But nobody has run it on Google Cloud, and we will not describe it as supported. If Google Cloud is your only option, the honest paths are the Kelynto Managed model once it is running, or a conversation about whether a container-based install on a virtual machine in your project would meet your requirements.

There is no packaged on-premises product, but there is a container path. A Docker Compose file runs the whole stack (API, scheduler, web, PostgreSQL) in single-tenant mode, and an overlay points it at a PostgreSQL server you already run. Both were built and run locally in production mode, the second against a separate database server over TLS, with the same post-deployment validation the cloud kits use. What is scripted around the single-machine variant (virtual machine creation, TLS certificates, encrypted backups) assumes an Azure virtual machine. On your own hosts you would supply the machine, TLS, backups, monitoring and outbound access to your identity provider's key endpoint. There is no Helm chart and there are no Kubernetes manifests. It has not been installed in any customer data centre, so treat it as an implementation project, not a download.

Yes, as an option of the deployment kit, and not yet proven on a live subscription. In every Azure shape PostgreSQL has no public endpoint and the API has internal ingress only, with one HTTPS entry point at the web tier. The private shape of the Customer Environment kit goes further: it deploys into a virtual network you already run, puts PostgreSQL, Key Vault and the container registry behind private endpoints, gives the application no public address at all (internal ingress), encrypts the database with a key you hold and sends logs to your own workspace. In the standard shape the registry and, by default, Key Vault accept connections from the internet with Entra authentication. An egress firewall is yours to add in either shape; the application needs outbound access to your identity provider's key endpoint and to any signal sources you leave on. The templates compile and lint; none has been deployed.

By design: database migrations run before the new code and are written to be backward compatible, so the previous release keeps serving on the newer schema during a rollout, and a rollback restores the previous images without touching the database. Every migration is classified in a registry, and a check fails the build if one is not. The upgrade script lists the migrations an upgrade crosses and stops for confirmation when one is not backward compatible; so far that is one of eleven (0006), which needs a maintenance window. On Azure a new revision takes traffic only after its readiness check passes. On the single machine an update restarts the containers, typically under a minute. In your own environment you decide when to apply a release. The scripts ran against stand-ins and locally; no upgrade has been performed on a cloud deployment.

There is a shared responsibility matrix for both models. Managed: Kelynto would operate the application, database, backups, monitoring, patching and incident response; you run your identity provider, assign roles, send the files and publish the reviews. Customer Environment: you own the subscription, network, keys, backups, monitoring recipients and outbound connections, and you decide when to apply releases; Kelynto publishes releases, fixes application vulnerabilities and supplies the runbook. Day-to-day operation (failed runs, capacity) is shared and should be agreed in the contract, including who is on call. Be aware that Kelynto is founder-led with no round-the-clock operations team, so in your environment your own team would be the first responder.

We cannot claim conformance. There is no WCAG conformance statement and no VPAT, and the product has not been tested with assistive technology such as screen readers; the independent QA lists that as not tested. What is in the code: visible keyboard focus styles, a skip link, reduced-motion support, labelled controls and menus, and light and dark themes. Those are good practice, not evidence of conformance. If accessibility is a procurement requirement for you, say so early: it would need a proper assessment before we could answer your questionnaire, and we would rather tell you that than tick a box we have not earned.

There is no availability commitment today and no operating history. The internal objective is that 99.5 percent of API requests succeed over 30 days; that is an objective, not a promise, and it only becomes a commitment if a contract says so. By design, the Azure production settings run two replicas of each application container across availability zones and a synchronous standby database in another zone. The simpler single virtual machine option has no redundancy at all. None of this has yet run on live infrastructure. If the service were down on a Monday, the weekly review is produced by a scheduler and can be rerun by an operator after recovery, and the pilot guidance is to keep your current fallback process during a pilot.

There is no tested list of supported browsers yet. It is a browser application with nothing to install, and to be exact about testing: the independent QA of version 2.2.0 exercised the app in Chromium only, and the later checks of the sign-up and upload screens did the same. Other browsers (Firefox, Safari, Edge) were not tested, and mobile widths were not part of that QA, although the review screen has a narrow layout. Edge and Chrome share the Chromium engine, which is a reason to expect them to behave the same, not a test result. There is no native mobile app. The app loads no third-party scripts or fonts and needs no browser extension. If your standard browser is Safari or Firefox, tell us before a pilot so it is checked first.

One codebase, two models. Kelynto Managed: a multi-tenant service that Kelynto would host on Microsoft Azure, each customer in an isolated workspace. Its status: designed and rehearsed, not yet running. No hosted service exists today. Customer Environment: the same software runs single-tenant inside your own cloud account, signing in with your directory; you own the account, network, keys and backups. Its status: available through enterprise implementation. The deployment kit for Azure is built and validated statically; it has not yet been deployed to a live subscription. A Terraform module for AWS is written and checked statically only, and a Docker Compose path for any container host ran locally. Either model would be stood up as part of an implementation, and the first deployment should be treated as a validation run.

Not yet. The product is built, tested and rehearsed on a development machine; it is not hosted anywhere, and the planned address, app.kelynto.com, is not serving it. What has been proven by execution locally: both container images build, the full stack runs in production mode, a complete customer onboarding passes with a mock identity provider, and a backup and restore works. What has not: any deployment to Azure, sign-in against a real identity provider, the live outside signal sources, and operation over time. So there is no uptime history, good or bad. It is working software that has not yet been operated for a customer. If you want to see it, the route today is a conversation and a walkthrough.

In the product: structured JSON logs with a request id on every line, health and readiness endpoints, and Prometheus metrics for request counts, latency, unhandled errors, rate-limit refusals and background runs. Logs carry time, event, request id, workspace and route, sometimes a user's email or id, and never request bodies or sales figures. In the Azure templates: an outside-in availability test and email alerts for database down, server errors, restarts and failed or missing weekly runs, with logs kept 90 days in the production settings. Limits: alerts go to a mailbox, there is no staffed round-the-clock operations team, read access is not audited, and none of the Azure monitoring has run yet because nothing is deployed. On a single virtual machine there is no alerting without an external uptime monitor.

Four parts. A React and TypeScript web app served by nginx. A Python API (FastAPI) that validates uploads, serves reviews and enforces sign-in, roles and workspace isolation on every request. A scheduler that produces each workspace's weekly review, closes stale runs and purges data past retention. And PostgreSQL, which is the only state. The weekly flow is: validate and load files, pull outside signals, run variance and attribution, build one facts document, write the commentary from those facts, then capture the planner's edits and verdicts. The API keeps no business state between requests, so it can be scaled out. The architecture document and the data-flow document with diagrams are available on request. Note that the product is built and rehearsed locally and is not yet running as a hosted service.

Stated plainly, not measured: more than 2,000 stores or 60 categories; several large workspaces in one database beyond a brief check with two and three; more than 50 concurrent users; several API replicas; a database on its own host; anything on Azure or other production hardware; weekly runs with live signal feeds or an AI writer; and the retention purge on a large workspace. Known slow points from the local tests: store-level variance views at 2,000 stores take about 0.2 seconds alone and 0.7 seconds under load, and refreshing per-store signal sources for 2,000 stores is thousands of sequential requests, so it should run as a separate job ahead of the review. A chain much above 500 stores should plan a sizing check on its own data volume first.

Only local test measurements exist, on synthetic data, on a small shared machine: 2 virtual cores, 8 GB, with the database, API and load generator on the same host, each test run once. At 500 stores and 60 categories the weekly run took about 2 seconds; at 2,000 stores about 4.5 seconds, with the template writer and no live signal refresh. Ingest ran at roughly 27,000 to 33,000 rows a second. With 50 simulated users pacing one request about every 5 seconds against a 2,000-store workspace in production sign-in mode, the median response was about 45 milliseconds and the 95th percentile about 0.4 seconds, with no errors. Treat every figure as plus or minus 10 to 15 percent. None of this was measured on production hardware.

Only the week's facts document: your company label, totals, region and category aggregates, the findings with store names and amounts, and the radar lines. The model does not receive raw rows, other weeks, other workspaces or any user details. So it does see business-sensitive aggregates for that week, including store names, which is why it is off unless your admin turns it on. If that is not acceptable to send to a third party, leave the default template writer on, which sends nothing anywhere, forbid language models for the whole deployment with one setting, or use the Azure OpenAI option with a resource in a subscription you control. We have not yet verified each provider's retention and training terms; that check is recorded before any provider is enabled for a customer.

AI text generation is off by default. The weekly commentary is written by a deterministic template unless an administrator switches a language model on. Cause attribution is rule-based, not AI. A model can be called only when an admin of your workspace enables an external writer and a provider key exists in the deployment; a deployment-level setting can also forbid it for every workspace. The providers the code supports are Anthropic, OpenAI and Azure OpenAI, and each would be a subprocessor only for workspaces that enable it; none has been called with real data, only test stand-ins. When enabled, the output is checked number by number against the week's facts and discarded if it fails, and a planner still reviews and publishes every review. The AI drafts business commentary about stores and categories; it makes no decisions about individuals. Provider terms would be checked and recorded before you enable one.

Yes. Every state change writes an audit event with actor, action, entity, request id, time and details: uploads, runs, commentary saves, publishing, cause labels, radar verdicts, settings changes (with before and after values), user changes, accounts created or re-roled at sign-in, operator commands, scheduled runs and retention purges. Admins read it in the app and through the API. It is kept for seven years by default (minimum one year), configurable per workspace. Limits: read access is not audited, so which records someone viewed cannot be shown; the database does not prevent an administrator with direct database access from altering audit rows; operator commands are recorded under the service user, not a named person; and there is no export to a SIEM.

Through your own identity provider using OpenID Connect: the authorization code flow with PKCE, a public client with no secret. The API verifies the signed access token on every request (signature, issuer, audience, expiry), accepts only RS256/384/512 and ES256/384, and decides the workspace from the token's verified issuer, never from a header. Setup is documented for Microsoft Entra ID, Okta and Auth0; any other standards-compliant OIDC provider should work the same way and has not been tested. To be exact: sign-in has been exercised only against a mock provider and locally signed tokens, so the first real token is checked step by step at onboarding. SAML is not supported. Your identity provider is registered by a Kelynto operator, not through a self-service screen. For teams without an identity provider the product also has its own sign-in by emailed link, off until switched on.

Yes, Azure OpenAI is one of the three supported providers. The deployment is configured with an Azure OpenAI endpoint, key and model deployment, and when your admin selects it the weekly facts are sent to that resource, so inference stays inside the Azure subscription it belongs to. In the Customer Environment model that can be your own subscription and your own resource. Two honest limits: the endpoint and key are deployment settings set by an operator, not something an admin pastes into a screen, and the AI writer has only been exercised with test stand-ins, not against a live Azure OpenAI resource. Other self-hosted or private model endpoints are not supported today.

By design, and not yet in operation. In the Azure templates the database has automated backups with point-in-time restore, kept 35 days in the production settings, with an optional copy in a second region and an optional standby in another zone. The single virtual machine option takes a nightly encrypted dump kept 35 days. Recovery figures in the documents are targets, not measured results: for example a recovery point of zero and recovery time of 15 minutes for a zone failure with the standby database, and up to 24 hours of data loss on the single machine. What has been tested: one backup and restore of the single-machine procedure, in a local rehearsal with synthetic data. No restore has been performed on Azure, and regional recovery is an outline only.

No. Kelynto has no SOC 2 report, no ISO 27001 certificate and no other third-party attestation, and no audit is in progress. It has not been assessed against HIPAA, PCI DSS or FedRAMP either, and its data contract has no field for cardholder or health data. We will not give a date for any of these here. What is available instead: the security overview with its list of what is not yet in place, the review pack with a pre-filled questionnaire, the architecture and data-flow documents, and the option to run the product inside your own cloud account so your own controls apply. The infrastructure the templates target is Microsoft Azure, whose physical and platform controls are covered by Microsoft's attestations, not ours. If an attestation is a hard gate for you, it is better to know that now; tell us and we will not waste your time.

One operator command deletes the workspace and every row it owns in a single transaction, checks that nothing with that workspace's id remains in any table, rolls back if anything does, and prints a deletion record with the time and row counts. That record is what we would send you; it is not a third-party certificate. Before deletion you can export your findings, radar outcomes, commentary and audit log. What remains, and we would tell you in writing: database backups hold the deleted rows until backup retention passes (35 days in the production settings), and logs hold request metadata, never sales figures, until log retention passes. In your own environment you delete the resource group yourself. The procedure was rehearsed locally, not yet on a live service.

The short version, with its limits. Sign-in goes through your own identity provider, so passwords and multi-factor authentication stay with you; Kelynto stores no passwords. Each customer's data is separated twice, in the application and again in the database with row-level security that shows a connection carrying no workspace nothing at all. Four roles are checked on every request, and every change is written to an audit log. The product holds weekly sales, plan and in-stock totals by store and category, never shopper, payment or employee data. AI text generation is off by default. Encryption in transit and at rest comes from the platform it is deployed on. There is no SOC 2 report or other attestation, no external penetration test and no hosted service yet; the product is built and tested locally. The Trust page lists every control with its status.

There is no guarantee about data residency today, because nothing is hosted yet. By design, data would be stored in one Azure region chosen at deployment; the templates default to East US 2, and geo-redundant backup, if enabled, adds the paired region. In the Customer Environment model the data sits in your own subscription and the region you choose. Things that cross the boundary regardless of region: store coordinates sent to weather and event services, and the weekly facts if you enable an external AI writer. Kelynto operates no data centre of its own. The region for a customer would be stated in the contract; until a deployment exists, we will not promise a location.

Yes, the product has its own sign-in without a password, for teams whose organisation has no identity provider connected. You enter your work email and receive a message with a single-use link and a six-digit code; either works once, and both expire after ten minutes. Sessions are kept on the server: you can list and end your own, and a workspace admin can end a member's session for their workspace. To be exact about today: this is built and tested, it is switched off in production until the operator of a deployment turns it on, and the product is not yet hosted as a live service, so nobody can sign in this way yet. It has one factor only, control of the mailbox; a workspace can require single sign-on through its identity provider instead. Mail delivery was tested against a local test server only. Kelynto stores no passwords in either case.

Precisely: the application does not encrypt business data itself; encryption comes from the platform it is deployed on. In transit, the app is served over HTTPS only with HSTS, and in the deployment kits PostgreSQL refuses connections without TLS. At rest, the kits rely on the cloud service's encryption for the database, its backups, secrets and logs, with keys the cloud provider manages by default. In a Customer Environment the kit can instead use a key you hold: on Azure for the database and its backups only, on AWS for the database, secrets, logs and registry (that module is checked statically only). Not available: field-level encryption and a separate key per workspace. On a single virtual machine, traffic between containers on the host is not encrypted, and backups are additionally encrypted to a key kept off the machine. None of the cloud settings has been deployed yet.

A written plan exists: severity levels, containment steps for suspected data exposure (disable the identity provider, deactivate the workspace or account, take the application offline if needed), evidence preservation, customer notices and a written review afterwards. The notification target is within 24 hours of confirming that your data or service is affected; the contract would govern. Stated limits: the plan has never been exercised, there has been no incident because nothing is in production, there is no round-the-clock team, alerts go to a mailbox, and because read access is not audited, which records an intruder read could not be shown from the application's own records. The named incident contact is still to be filled in by the founder.

We list them openly. The workspace a transaction is bound to is an ordinary session setting, so a flaw that let an attacker run arbitrary SQL as the application role could set it to each workspace in turn. In the supplied templates the application's database role owns its tables, so the same kind of flaw could alter a policy; a stricter two-role layout was rehearsed and tested but is not yet the default. The table of workspaces (names and settings, no sales data) is readable by the application role. Record ids are sequential across workspaces, so a customer could estimate overall volume. Operators with database or container access can see all workspaces. And no independent party has verified any of it. These are in the security overview under Not yet in place.

The security overview keeps an open list, and the trust page labels every control. The main items: no third-party attestation and no external penetration test. Identity providers are registered by a Kelynto operator, with no self-service screen. No SCIM. Tokens are not checked for revocation with your provider. The built-in emailed sign-in has no second factor. The application's database role owns its tables in the supplied templates. Rate limits are per process. Background runs have no durable queue. Uploaded files are not virus-scanned (they are parsed as data and discarded). Read access is not audited and the audit log is not tamper-proof. No field-level encryption, no egress firewall in the kit, no SIEM export. The retention purge does not rewrite backups. Browsers other than Chromium are untested. And nothing has run on live infrastructure yet. The full list is in the overview; ask for it.

Technically, in the managed model, anyone with operator access to the production environment could: opening a shell in the API container gives access to every workspace's data, and shell sessions are not recorded by Kelynto. Control-plane actions would be in the Azure activity log, and operator commands that change data are written to your audit log, under a service user, not a named person. The names and number of people with access, staff screening and whether administrative access requires multi-factor authentication are organisational facts the founder has still to state in the review pack; we will not guess them here. If this is a concern, the Customer Environment model changes the answer: Kelynto staff see your data only if you grant access to your subscription.

No, for two reasons. First, there are none: Kelynto has no customers yet, so there are no other retailers' results to show. Second, even when there are, the answer stays no. Each customer's workspace is isolated in the application and in the database, a request for another workspace's record returns not found, and one customer's data, labels and scorecard are not shared with another. The assistant on this site has no access to any workspace data at all. What you can see is the demonstration workspace, Harborview Markets, which is synthetic and labelled as such, and a backtest on your own past weeks.

Four things exist today. A security overview written for a retailer's security and IT review, covering data handled, sign-in, workspace isolation, audit, AI use, platform controls and a plain list headed Not yet in place. A control register, shown on the Trust page of this site: every control with one status (implemented, available through enterprise implementation, planned, not in place) and the file or test that shows it. A security review pack: a pre-filled questionnaire in the style of CAIQ Lite and SIG Lite, architecture and data flows with diagrams, a subprocessor template, an incident response and recovery plan, and a shared responsibility matrix. And the deployment document with a record of what was proven by execution and what was not. The pack still has founder-input markers for organisational answers, so it is completed before it is sent. There is no third-party attestation. Ask for the pack and name the reviewer.

No passwords are stored, in any sign-in path. With your own identity provider, the application only verifies signed tokens, so multi-factor authentication and conditional access are enforced by your provider under your policies, and Kelynto inherits them. The product's own sign-in, for teams without an identity provider, uses an emailed single-use link or code, stored only as hashes; it has one factor, control of the mailbox, and no second factor of its own, and a workspace can require single sign-on instead. It is off in production until switched on. There is no emergency login that bypasses these. A development header sign-in exists for local demos, and the service refuses to start with it in production mode. On an optional shared provider for customers without single sign-on, credentials and multi-factor settings would be held by that provider and configured by Kelynto.

No. There has been no third-party penetration test and no external security audit. What has been done is internal: an independent QA and security pass inside the project, run locally against the release, covering cross-workspace access, role escalation, token attacks, upload abuse, injection and server-side request forgery, with the open findings fixed or listed. That is not a substitute for an external test and we do not present it as one. Whether a customer may run its own test, and against which environment, is a contract question that has not been decided. Automated dependency and image scanning is configured in the build pipeline but that pipeline has not yet run.

Yes, in the application: 600 requests a minute per signed-in user, 60 a minute per client address for requests without valid credentials, and 20 a minute for uploads and run triggers, each with a burst allowance. A refused request gets a 429 with a retry time. An upload's token, role and limits are checked before its body is read, and the size limit is applied as it arrives. Limits to know: the counters are per API process, not shared across replicas, so treat this as the inner layer; a web application firewall is optional in the Azure templates (Front Door) and off by default; there is no dedicated DDoS protection plan; and the early upload refusal was verified behind the supplied nginx only, not behind Azure's ingress.

Retention is a setting per workspace. Business data is kept 730 days by default (minimum 30): weekly sales, in-stock and promotion rows, weekly runs with their findings, labels, commentary versions, radar items, pulse answers, signals and upload records. A daily purge deletes what is older and writes an audit event with the counts. Stores, user accounts, identity provider settings and workspace settings are kept. The audit log is kept 2,555 days by default (seven years, minimum 365) and never less than the data retention. One limit to know: the purge deletes rows from the live database only. Backups keep them until the backup retention has passed, and backups cannot be edited selectively.

Four roles (viewer, planner, analyst, admin) are checked on every API route, not just hidden in the interface. With your own identity provider, roles come from the token's roles claim: an account is created the first time a user with a role signs in, and removing the role in your directory revokes access on the user's next request. A deactivated account in Admin always wins. Limits, stated plainly: there is no SCIM provisioning; tokens are not checked against your provider for revocation, so a token already issued stays valid until it expires, which is why access token lifetimes should be an hour or less; and accounts are matched by email, so the email claim must come from an attribute users cannot edit.

No. There is no SLA, no uptime commitment and no service credits today. There are internal objectives, for example that 99.5 percent of API requests succeed over 30 days and that the weekly review is produced within an hour of its scheduled time, but they are objectives, not commitments, and nothing has run in production to measure them. Recovery point and recovery time figures in the documents are design targets, not measured results. The guidance for early pilots is pilot-grade availability stated openly in the agreement. Any commitment would be made in a contract, after the hosting model for your deployment is chosen. If a formal commitment is a precondition, raise it in the first conversation.

Today, none: nothing is deployed and no company is engaged, so the subprocessor register is a working document. What each option implies: in the Kelynto Managed model on Azure, Microsoft holds everything stored. A language model provider (Anthropic, OpenAI or Azure OpenAI) and PredictHQ apply only if your admin switches those features on. A mail delivery provider applies only where sign-in by emailed link is switched on. Customers on a shared sign-in provider add that identity provider. Weather services receive store coordinates only and are listed for transparency. In the Customer Environment model the software runs in your account, Kelynto holds none of your data and engages no subprocessor for it. The list for your deployment, with regions and how changes are notified, would be fixed in the contract; no notice process exists yet.

In the managed model customers share one application and one PostgreSQL database, separated by two independent layers. In the application, every query from a workspace-bound session is filtered by workspace and writes for another workspace raise an error. In the database, row-level security is forced on all twenty-three customer-owned tables for reads and writes, and the application connects as a role that cannot bypass it. The policy fails closed: a transaction bound to no workspace sees no customer rows and can write none. A request for another workspace's record returns not found. Automated tests cover both layers, including raw SQL. No independent party has tested it. If shared infrastructure is not acceptable, the Customer Environment model is single tenant in your own account.

No. Kelynto does not use customer data to train any model. Attribution is a rules engine, so there is no model of ours to train. The labels your planners create adjust the confidence priors inside your own workspace only, stay in your workspace and can be exported by you. If your admin enables an external AI writer, the provider you choose receives the week's aggregated facts, and that provider's own API terms govern what it does with them; we have not yet verified those terms for each provider and would record them before you enable one. Any use of anonymised learnings across customers would have to be agreed in your contract; nothing in the product does it.

Built and configured, not yet running in a pipeline, which is why this is labelled planned. Python packages are pinned to exact versions used by both the tests and the image; JavaScript packages are locked; build actions are pinned to commit hashes. The build workflows audit dependencies, scan both container images, block deployment on a critical vulnerability with a fix available, and attach a software bill of materials. Run by hand on 2 October 2026, the dependency audits found no known vulnerabilities. The honest gaps: the workflows have never run, no scan result exists for the real images, there is no secret scanning tool, no written patching deadline by severity, and base images are pinned by tag, not digest. An automated backend test suite of more than 800 tests at version 2.3.0, including database isolation tests, has to pass before a release.

Two ways, both reach the founder directly. Book a 20-minute conversation at https://calendly.com/kelynto, or write to marc@kelynto.com. There is no sales team and no call centre; Marc Estinville, the founder, answers. For a first conversation it helps to say your role, roughly how many locations you have, what your plan is built in, and what prompted the question. For a security or procurement review, say who the reviewer is and which hosting model you are considering, so the right documents are sent. There is no phone line, chat with a person, or support desk today.

Honestly, little is final. What exists is an outline of a short pilot agreement, written for a lawyer to turn into the actual letter; it is not yet a finished contract. The onboarding checklist expects that agreement to name retention periods, deletion on exit and incident contacts on both sides, and the shared responsibility document lists what a customer should ask to have written in: hosting option and region, subprocessors, retention and deletion, incident notification, any availability commitment, and whether an AI model may be enabled. There is no master services agreement, no published terms of service and no data processing agreement template today. Questions about your paper or your NDA go to the founder. Nothing here is legal advice.

The self-service route is built, and it is not open yet. In the product, a person signs in with an emailed link or code, creates a workspace for their organisation (name, time zone, first day of the fiscal week, currency), becomes its first admin, invites colleagues by email with a role, and loads data through an upload preview that shows how each column is read before anything is stored. Whether sign-up is open, by approval or by invitation is decided by whoever operates the deployment. Today the product is not hosted and sign-up is switched off in production, so there is nowhere to do this yet. Until the hosted service is live, a workspace is created by a Kelynto operator as part of onboarding, and the way to start is a pilot conversation. This answer changes when the site reports sign-up as open, and not before.

There is no Kelynto data processing agreement template today, and whether Kelynto will sign a customer's own is a founder decision that has not been recorded, so we cannot say yes here. What exists are the facts such an agreement needs: the categories of data (weekly business aggregates and users' business contact details), the subprocessor template per hosting option, retention and deletion behaviour, and the incident notification target. In the documents Kelynto's role is processor and the customer is controller. Standard contractual clauses and cross-border transfer terms have not been prepared. If a signed agreement is a precondition, raise it at the start so it does not surface in week three. This is not legal advice.

Pricing is not finalised. It will depend on deployment model, number of locations and pilot scope. The fastest way to get a number for your situation is a 20-minute conversation.

That is the whole answer for now: there is no price list, no per-store or per-user rate and no discount schedule to quote, and the assistant cannot estimate, hint at a range or negotiate. If someone gives you a number that did not come from the founder in writing, it is not a Kelynto price. To get terms for your situation, book 20 minutes at https://calendly.com/kelynto or write to marc@kelynto.com, and bring your number of locations and preferred deployment model.

We do not publish a dated roadmap, and the assistant will not promise delivery dates. What we can say precisely is where things stand. Built and tested, and waiting for the hosted service to go live before anyone can use them: the one-click sample workspace, self-service workspace creation with sign-in by emailed link, and invitations. Built and not yet proven on a real cloud account: the Azure deployment kit and the AWS Terraform module. Not built: a connector to any planning suite, a Google Cloud kit, a Kubernetes chart. Separately, the security overview lists known gaps under Not yet in place, such as a second factor for emailed sign-in and shared rate-limit counters; a gap on that list is an acknowledged limitation, not a dated commitment. The changelog shows what has actually shipped. If a specific capability decides things for you, tell the founder.

It is built, and it is not open to visitors yet. The sample workspace is a private copy of Harborview Markets, a synthetic retailer with 36 stores: a story in each of the latest weeks, confirmed and rejected causes, a Forward Radar and a Scorecard with at least twelve reviewed weeks. A visitor opens it from the site in one click, without an account, can look through each role, and the copy is deleted after 24 hours. What stops that today is that the product is not hosted: the site shows the link only when the product itself reports the sample workspace as on. Until then, the product tour on the site shows the product's screens with the same synthetic retailer, and the founder can walk you through it live in 20 minutes. It is labelled as synthetic everywhere: its numbers show the experience, not results.

There are no defined support hours, no help desk and no round-the-clock coverage today, and we will not imply otherwise. Kelynto is founder-led: during a pilot the same person is the pilot lead and, in the managed model, the operator. The documents state that alerts go to a mailbox and that there is no staffed operations centre. What is planned into a pilot: a kickoff, reading the validation reports with your data contact, walking your planner through the first draft, a weekly check-in and a readout. Response-time targets for incidents exist as internal targets and become commitments only through a contract. If your organisation needs contracted support hours, raise it before a pilot so it can be answered in writing.

Not yet, and we would rather say so than send you to a form. Two self-service routes are built: a one-click sample workspace filled with synthetic data, and creating your own workspace with sign-in by emailed link. Neither is open, because the product is not hosted yet; the site shows those two links only once the product itself reports them as on. What you can do now without a call: take the product tour on the site, which shows real screens of the product with the synthetic demonstration retailer, read the deployment and trust pages, and ask this assistant. To see it working on your own questions, the route today is a 20-minute conversation with the founder, who is the only person you would be talking to; there is no sales team. Book at https://calendly.com/kelynto.

Kelynto was founded by Marc Estinville, who has more than 17 years in retail supply chain and planning technology. The product comes from that work: the weekly task of explaining to leadership why sales missed or beat plan, which often falls to a planner and a spreadsheet. In a pilot you would work with Marc directly; there is no account team in between. His background is context for why the product is shaped the way it is. It is not a customer reference, and Kelynto has no customers yet. You can reach him at marc@kelynto.com or book 20 minutes at https://calendly.com/kelynto.

Kelynto is a coined name. That is all we say about the name itself. It is written as one word with a capital K, and the website is https://kelynto.com. What the name refers to is easier to describe: Kelynto is an enterprise planning intelligence platform for retail planning organizations, and its tagline is "Your Monday business review, already explained."

A fair question for a founder-led company. What is true today: your raw sales and plan data came from your own systems, so you never depend on us for it. What Kelynto adds, the commentary, cause labels and radar outcomes, can be exported by your analysts and admins at any time. Nothing in your planning process depends on it, so if it stopped, you would return to how you work today. In the Customer Environment model the running software and all data sit in your own cloud account. What does not exist: source code escrow, a continuity arrangement with a third party, or a commitment about a wind-down period. Those would be contract terms, and they have not been decided. Raise it with the founder and expect a straight answer.

Early. Kelynto is a founder-led company with a working product and no customers yet. No retailer has run a pilot, there are no results, references or logos, and the product is not yet hosted as a live service. It has been built, tested and rehearsed locally on synthetic data, and the documents say exactly what was proven and what was not. We tell you this first because you would find it in diligence anyway. What an early company can offer is direct access to the person building it, a pilot measured on a scorecard agreed up front, and the option to run the software in your own cloud. Details such as team size and funding are for a conversation with the founder.

What we can state here: Kelynto is early and founder-led, with no customers yet. Beyond that, the assistant does not have verified facts about headcount, investors, funding, runway or office location, and it will not guess or round up. Those are reasonable diligence questions and they deserve an answer from the founder directly, in writing if you need it for a vendor file. Write to marc@kelynto.com or book 20 minutes at https://calendly.com/kelynto. If vendor size is a hard criterion in your procurement process, it is worth asking before you invest time in a review.

You should not trust us on our word, and the product is set up so you do not have to. Nothing replaces your current process: Kelynto sits above your planning system and writes nothing back. A backtest on your own past weeks shows the fit before anyone changes how they work. The pilot is judged on a scorecard computed from your planners' own actions. The security overview lists what is not in place. You can export your labels and commentary at any time, and deletion on exit is a documented procedure. If you host it in your own cloud, the software and data sit in your account. The real cost of going first is your team's attention for a few weeks, and the vendor risk of a founder-led company, which is a fair concern to weigh.

This is an automated assistant, not a person. It answers questions about Kelynto from an approved knowledge base, each answer with a status label, and it has no access to any workspace or customer data. It works in one of two ways. When the product's own service is not reachable (it is not hosted yet), your question is matched in your browser against answers published with this site: nothing is sent or stored. When it is connected, conversations are stored so the team can see which questions go unanswered. As built: the client address is never stored (only a keyed hash that changes every day, for abuse control), no cookies are read or set, and email addresses, phone numbers, card-like numbers and credentials are removed before storage. By default conversations are kept 180 days and contact details you submit with consent 730 days. To reach a person or have your data removed, write to marc@kelynto.com.

Nobody yet. Kelynto has no customers, no completed pilots, no case studies, no references and no logos, and we will not name or hint at any retailer. The product has been built and tested on synthetic data. What we can offer in place of a reference is a way to check it yourself: a backtest on four to eight of your own past weeks, set beside what your team actually wrote, and a pilot judged on four measures agreed before it starts. If having a reference customer is a requirement for you, that is a fair position, and the right answer is to come back later. If you are open to being among the first, start with a 20-minute conversation.