Daybreak

The counterparties are named by product, not by category, each shown with its logo and the specific data it supplies. They run from SAP ERP and the Snowflake data warehouse to messaging in Outlook, Microsoft Teams and Slack, and to documents in Microsoft Excel, SharePoint, Dropbox and PDF sources. Nine named systems across four classes, from ERP and a cloud data warehouse to messaging and document stores, so this is not a catalog bounded to one ecosystem.

Every documented flow reads rather than acts. Sol reads these systems to prepare context; Dawn produces a recommendation; the recommendation is submitted, reviewed and scored inside Daybreak; and the output reaches a person through a worklist or an email. Nothing published describes a write back into SAP or any other system of record: no posted forecast, no updated planning object, no authenticated transaction in a customer system. On a planning product that is a material limitation, because committing the plan to the ERP is where a planning tool either acts or hands over.

It is also a short fixed list with no way to add your own. No custom tool support, connector SDK, authenticated action framework or integration catalog page is published; the nine sources appear as an illustration inside one worked example, not as a maintained directory.

Sourcedaybreak.ai/product context preparation source panelread 2026-09-14

The execution is multistep, and each step is documented: a five moment cycle running context prepared, decision owned, exception governed, judgment carried forward and outcome scored, each with its own named actor, trigger condition and artifact, traced end to end on a worked example from Monday 5:30 AM to the outcome scored three weeks later.

It is multi agent and multi participant. Two named agents with different jobs hand off to each other (Sol prepares context, Dawn decides), and a third participant class, the planners, is routed to conditionally. People and agents compose one governed flow.

The branching is conditional and driven by policy: each decision is evaluated against a stability threshold and either executes autonomously or routes to review, so a single cycle splits 1,200 decisions into 960 autonomous and 240 suggested. It runs at scale and carries state between steps: the accepted recommendation, the added context and the policy adjustment all carry forward into the next cycle.

The cycle is fixed by the vendor. The customer configures policy bounds and automation scope, not the sequence, and no workflow authoring surface, named runtime, BPMN or graph, or versioning is published.

Sourcedaybreak.ai/product five-moment cycle, daybreak.ai homepage cycle volumesread 2026-09-14

The sourcing is broad and spans structured and unstructured material. Sol prepares each cycle from nine named surfaces. SAP ERP supplies demand, inventory and shipments, Snowflake holds 18 months of point of sale sell through history, and Excel carries the promo forecast workbooks. PDFs hold supplier contracts and lead time terms, Outlook the buyer correspondence and Slack a named planning channel.

The weekly S&OP standup notes come from Microsoft Teams, the S&OP review decks and cycle minutes from SharePoint, and a legacy planning archive from Dropbox. Reading supplier contracts and meeting minutes alongside ERP tables is real comprehension work, and the treatment is described: "Source data validated, planning inputs structured, integrity issues flagged. All before any decision is made."

Grounding is visible in the output: decisions carry the signal they rest on, and a planner's contribution is attached as a document (atlanta_q3_endcap.pdf, 142 KB) rather than paraphrased.

No maintained retrieval structure is documented. No index, graph, embeddings layer, vector store or retrieval mechanism is named anywhere on the site, and nothing describes a queryable knowledge layer that persists and scales past a context window. What is documented is an ingestion and validation pipeline feeding a forecasting model, with inputs assembled and structured for a cycle. The 18 month POS history is a data range, not evidence of a retrieval structure over it. Context is assembled per run, however many sources it draws on.

Sourcedaybreak.ai/product context preparation and ingest sourcesread 2026-09-14

Daybreak ships a review and approve surface with a threshold, a queue, a verdict and a reason. The gate is the vendor's own and is driven by thresholds. A recommendation that exceeds a published policy bound does not execute: "Because the change exceeds the 20% stability threshold, the decision routes to review with reasoning, alternatives, and guardrails attached." The agent says it in its own voice ("My recommendation is exceeding your policy threshold. I need your input."), and the decision sits at Awaiting input until a person acts.

The queue is named, populated and split by disposition. The Demand Worklist shows 1,200 decisions for a cycle as 960 autonomous and 240 suggested, each held item carrying its own hold reason ("Held: high-impact decrease, large forecast change"; "large forecast change, DC concentration"). Hold reasons on each item are risk tiering in operation, not a claim about it.

The verdict surface is explicit: Override and Accept are the two documented actions, with Submit override as the committing step, a free text Why field, and the resulting value shown against both the ML baseline and the agent's number.

The scope is set by the customer, which separates a gate from a disclaimer: "See every decision. Choose what to automate," and "Agents own the decisions. You own the bounds, the audit trail, and the kill switch." A buyer sets the bounds that decide which calls come back to them, and the kill switch is a documented stop.

No approval hierarchy, delegation or escalation path to a second approver, segregation of duties statement or record of who approved is documented; the person who reviews is the planner who owns the worklist.

Sourcedaybreak.ai/product five-moment cycle, daybreak.ai homepage Demand Worklist and forecast reviewread 2026-09-14

Both halves are named on one first party line. The product page closes its autonomy section with a line naming SOC 2 Type II, RBAC, SSO, and encryption in transit and at rest: a named attestation, and a named access model with identity integration. RBAC and SSO both speak to who inside the buyer's organization can make an agent do what.

The trust center at trust.daybreak.ai resolves but blocks automated reading; a buyer with a browser reaches it, and it is where scope, auditor, report date and subprocessors would be listed. daybreak.ai/security is a responsible disclosure page only, naming a Sprinto hosted vulnerability program with a seven business day response commitment, a 90 day confidentiality window and no bug bounty; it documents no controls. No documentation site exists to search for admin SSO or SCIM material.

The attestation and controls are stated on a strip at the foot of a product page rather than on a controls page a buyer can read without a call. No SCIM, named auditor, report date or penetration test scope appears anywhere reachable.

Sourcedaybreak.ai/product control strip, daybreak.ai/security, trust.daybreak.ai bot-blockedread 2026-09-14

The unit of audit is the individual agent decision, and it carries an identifier. The override record shows DEC-7842 with a timestamp (Apr 13, 4:20 PM), the prior value, the new value, the delta and the free text reason. Decisions are addressable objects, not log lines.

Reasoning is retained, not just outcomes. Every call carries "its own reasoning and guardrails"; the page states "every decision logged" and "reasoning on every call"; and on the human side "your edits, confidence, and reasoning are captured." A buyer can reconstruct why a number moved, not merely that it moved, including the alternatives the agent rejected, since the candidate set is retained (4,600 recommended, 3,900 conservative, 5,200 aggressive) alongside the threshold that routed it.

The audit trail is named as the customer's: "Agents own the decisions. You own the bounds, the audit trail, and the kill switch." A durable artifact for each cycle exists beside the live view, since the agent's cycle summary links to a cycle report, and history can be queried in aggregate, with 12M+ decisions scored and trends by category held over at least six cycles.

What is counted is the record of what the agent did: which decisions it made, on what reasoning, against which alternatives, under which policy, and what a person did to them, not readings on the customer's supply chain. No retention period, export path, admin view across users, or alerting or monitoring surface is documented; the trail is described on a marketing page rather than in operator documentation, and no documentation site exists.

Sourcedaybreak.ai/product decision log and reasoning panels, daybreak.ai homepage cycle reportread 2026-09-14

A named store is documented and its contents are shown. The fourth moment of the planning cycle is headed "Judgment carried forward" and carries a panel labeled "Dawn's memory" listing its entries, such as "Southwest heat wave from Memorial Day forecast -> sun-care +18%," "Atlanta Q3 endcap shifted to Sept 24. Apply earlier ramp on Sunscreen SPF 50," "Holiday gifting peak +22% YoY for family-pack beverages cohort," "Pacific Northwest rain forecast suppresses outdoor SKU velocity 6-9%" and "Retailer B endcap windows confirmed for Q4. Lock 4-week lead."

The user writes it in natural language and the agent reads it back across cycles. The planner types free text into an exception ("Atlanta team confirmed Q3 endcap moves to Sept 24, not Oct 1") and it appears as a memory entry, with the agent confirming: "Atlanta's endcap timing is locked in. I'll apply the earlier ramp next cycle." The homepage states the retention plainly: "Your edits, confidence, and reasoning are captured so your judgment is never lost." That is a store of facts the user maintains and the agent consults across sessions.

The agent reads these as context to decide: the seasonal and retailer calendar entries are facts feeding a judgment, not settings applied mechanically. One entry, "Personal care POS variance > 15% -> flag for human review," is a rule the product applies rather than a fact the agent weighs.

No lifetime is stated: no retention period, expiry, purge path or way to delete one customer's memory without touching the business record. Scope is per agent and per tenant by implication and is not stated.

Sourcedaybreak.ai/product judgment carried forward panel, daybreak.ai homepage override captureread 2026-09-14

One region is named, flatly: "Our services are hosted in the United States." The privacy policy describes the direction of travel as inbound to that single region: users in the EEA, the UK and other regions are told their personal information "may be transferred outside of those regions to the United States for storage and processing." A buyer with a different requirement cannot get a different answer.

The legal machinery around the transfer is not residency. The privacy policy names adequacy decisions, the EU Commission's standard contractual clauses and Binding Corporate Rules as safeguards for moving data out of the EEA and UK. A vendor invoking transfer safeguards is saying the data leaves rather than that it can stay.

No region list, customer environment option such as VPC, on premises or customer tenant, or selection surface is published, and the site does not say options may be available on request.

Sourcedaybreak.ai/privacy-policy hosting and international transfer sectionsread 2026-09-14

Daybreak packages two named agents with distinct published roles. Sol, the operator agent, prepares context: source data validated, planning inputs structured, integrity issues flagged. Dawn, the planning agent, owns decisions: repeatable planning calls run under policy, each carrying its own reasoning and guardrails. Dawn has a persona, a worklist, a mailbox at dawn@daybreak.ai and a logo in the site navigation, so it is a named unit of the product rather than an internal component the buyer never hears about.

The two are stages of one pipeline, not two products. Remove Sol and Dawn has no validated context to decide on; remove Dawn and Sol prepares inputs for nothing. Both run in every cycle by construction, and the buyer never selects between them.

Nothing a customer can adopt is published: no catalog, template library or page for each agent with a durable URL. The policy thresholds a customer configures are bounds on a gate, not packaged assets.

Sourcedaybreak.ai/product Sol and Dawn cycle roles, daybreak.ai homepage Dawn worklistread 2026-09-14

A schedule is documented explicitly. The homepage defines AI labor as "scheduled work performed by agents, producing planning decisions your team governs." The cycle is the scheduling unit, named and dated throughout: "Mar 16 cycle ready for review," a worked cycle beginning Monday, 5:30 AM before any planner is at a desk, and weekly cycle identifiers (Wk11 through Wk16). Agent work starting unattended on a recurring cadence is a real trigger.

A second trigger exists internally: a policy threshold breach fires an escalation, moving a decision from autonomous execution into a human queue, with the threshold rather than a person deciding. That is an event the platform raises about its own work.

Delivery reaches the planner outside the application too: Dawn sends an addressed email from dawn@daybreak.ai summarizing the cycle and itemizing what needs a decision, alongside the in product Demand Worklist.

Only a schedule starts work from outside. No webhook, event subscription, inbound queue or API trigger is published, and nothing describes an external system (an ERP posting, a POS feed, a supplier signal) firing a Daybreak agent as it arrives. The connectors are read on the schedule's terms, not watched for changes, so a demand signal that lands on a Tuesday waits for the next cycle.

Sourcedaybreak.ai homepage AI Labor definition and cycle cadence, daybreak.ai/product Monday cycle openread 2026-09-14

Daybreak names no model provider, family, version or routing arrangement on any of five first party pages: the homepage, /product, /about, /security and /privacy-policy. The site's vocabulary is agents and outcomes, AI labor, with agents that make decisions under policy. The only technical marker is an ML column in the forecast review table, beside Dawn's number and the human override, which shows that a machine learning baseline exists and says nothing about what produces it.

The privacy policy is the strongest evidence of the absence. It lists third parties in detail, naming Google Analytics, LinkedIn Insights and PostHog as analytics partners, and names no model provider or AI subprocessor anywhere.

No customer choice of any kind is documented: no model selector, admin entitlement, model parameter per agent or run, bring your own key or bring your own model path. A buyer is not told what runs, let alone offered a choice.

Sourcedaybreak.ai homepage, /product forecast review ML column, /privacy-policy third-party listread 2026-09-14

No developer surface is published. The site's navigation is small and fully enumerable, and neither the header nor the footer has a developers entry, documentation, an API reference, an integrations page or a partner or marketplace listing. The single call to action everywhere on the site is a Calendly booking to talk to the founding team.

daybreak.ai/security is a responsible disclosure page for reporting vulnerabilities, not a developer resource, and no documentation subdomain is linked. The site makes no API claim of any kind, and no MCP server, CLI, marketplace, A2A agent card, webhook or embed is documented.

Reading nine third party systems is the platform reaching out to someone else's systems; it says nothing about whether this platform can be called.

An enterprise vendor selling through sales may expose an API under contract without publishing it, and the trust center at trust.daybreak.ai blocks automated reading, so a subprocessor or architecture page there could disclose an interface. What is published is nothing.

Sourcedaybreak.ai header and footer navigation read on five pages, daybreak.ai/securityread 2026-09-14

The loop is the product's central claim: "the first planning system that scores every decision against the outcome." Three weeks after a decision is made the realized sell through is compared against it, and "Dawn grades each decision based on the outcome, captures what added value, and folds it into the next cycle." That is a controlled optimization loop running after deployment.

What is measured is the agent. The Decision Quality Score is performance against a control, "outperformed the unmodified baseline," reported as +5.4% and tracked per cycle (+1.8, +2.6, +3.1, +4.2, +5.4 across weeks 12 to 16) and per category over six cycles. The Override Value Score runs the same comparison on the person: "Override cut forecast error by 6% vs Dawn's baseline." The forecast review table carries an ML column beside Dawn's number and the override, so three candidate values for one period are held against the actual.

The loop reports its own failures, which is the strongest evidence it is a measurement surface rather than a marketing number. The trend by category shows Household running negative (+4, +5, +6, then −1, −2, −3) while Beverages climbs, and the agent says so: "I keep climbing in Beverages. I miss in Household. Your overrides help there."

The vendor's headline figures, $7M a month in inventory reduction, 12M+ decisions scored and 98% auto executed, are its own published benchmarks; the shipped scoring of each decision is the stronger evidence. No methodology is published for either score: no definition of the unmodified baseline, no attribution window beyond the three week example, and no way for a buyer to configure or export the comparison.

Sourcedaybreak.ai/product outcome scoring, daybreak.ai homepage Decision Quality Score trendread 2026-09-14

No hosted or local browser, desktop session, or remote or local computer control that the agent drives itself is documented across five first party pages. The product is a planning application a person opens, and the agent's work happens inside it; the product running in a browser is not an agent operating a browser.

The ingestion estate is the near miss. Sol reaches nine third party systems each cycle, several of them ordinarily operated by a person through a screen, namely Outlook correspondence, a Slack channel, Microsoft Teams standup notes, SharePoint decks and a Dropbox archive. That fetch builds the corpus the work later queries rather than doing the work: it happens in the first moment of the cycle, "all before any decision is made," and its output is validated and structured planning inputs.

The usual buyer questions do not apply. Nothing suggests targeting UI elements; these are data connections to SAP and Snowflake. The approval model governs forecast decisions, not interface actions.

Dawn sends an addressed email from dawn@daybreak.ai summarizing a cycle, which is a delivery channel rather than the agent operating a mail client.

Sourcedaybreak.ai/product context preparation, daybreak.ai homepage delivery surfacesread 2026-09-14