Two ways to notice strain, and only one of them watches the worker

The two designs hiding behind one phrase

Ask three vendors how they detect burnout and you will get three answers that sound similar and behave nothing alike. The first design starts from traces: calendar load, message counts, after-hours activity, ticket volume, response latency. It treats those traces as evidence of an inner state and produces a judgment the person never wrote down. The second design starts from what the person said. It asks a question, keeps the answer with them, and reports upward only what qualifies at a group size large enough to publish.

The distinction is not about how sophisticated the model is. Both designs can be built well. It is about who authored the input. A trace is something you left behind while working. A check-in is something you decided to say. When a result about a person is later challenged, the first design has to defend an inference and the second has only to show the sentences the person wrote.

That difference decides the rest of the program. It sets what an employee has to trust, what a works council will ask about, whether participation is voluntary in more than name, and what happens to the output when a manager wants to know who is on the list. It also decides whether the tool is describing a person or describing the work.

• Inference-first reads traces the person did not author, then names a state.
• Share-first reads what the person chose to write or say, and nothing else.
• Only one of them produces a claim the person can inspect and argue with.
• Only one of them is safe to describe in full at an all-hands meeting.

What behavioral inference actually reads

Two published examples show the range, and both are worth reading in the vendor’s own words rather than in a summary. Microsoft documents a Viva Glint feature called Continuous Engagement that brings workplace metrics from Viva Insights into Viva Glint so managers can track engagement drivers between survey cycles. The metrics named in the initial release are activity measures: after-hours collaboration hours, uninterrupted focus hours, meeting hours, collaboration hours, and internal network size. Microsoft states the metrics are aggregated at a group level, that the feature does not provide individual-level insights and does not evaluate employee performance, and that metrics appear only when both products’ confidentiality thresholds are met, with the higher value enforced when they differ.

Two qualifications travel with that feature and are frequently dropped. Microsoft documents it as available in preview, with features and behavior that may change before general availability, and tenants must contact the Viva Glint team to have it enabled. It is not a shipped Viva Glint capability and its presence cannot be assumed for any customer, so a buyer comparing it against something that ships today is comparing unlike things.

The second example is contractual rather than behavioral. Qualtrics’ Employee Experience product terms define Continuous Employee Listening as permitting the customer to process unstructured sets of data related to its employees, measured in Interactions, and enumerate the interaction types as survey responses, internal email threads, chats and direct messages, internal service-desk tickets, public online review threads, and voice, comprising call transcripts or recorded voicemail and call audio files. That is what the SKU is licensed to ingest. It is a definition of scope, not a description of what any customer has switched on, and it is not evidence that any employer ingests employee email, chat, or voice. Qualtrics also states on its HR page that it anonymises every employee response before it reaches any analysis, which is the company’s own published assurance about its own handling, recorded as theirs.

Both examples make the same practical point for a buyer. The question is not whether a vendor could ingest more than survey answers. It is what your contract permits, what your configuration turns on, and what your employees have been told in language they can check.

The line the EU AI Act draws at the workplace door

Article 5(1)(f) of Regulation (EU) 2024/1689 prohibits placing on the market, putting into service, or using AI systems to infer emotions of a natural person in the areas of workplace and education institutions, outside narrowly drawn medical or safety exceptions. That is a prohibition on a category of system, not a documentation requirement you can satisfy with a disclosure. It is the single sharpest constraint in this market and it lands directly on the inference-first design.

Daylogue does not infer emotion from faces, voice tone, or physiology. It works from the words and context people choose to share. That sentence is written the same way in the product, in the investor material, and here, because a boundary that changes wording by audience is not a boundary.

The practical version for a buyer is short. If a vendor’s demo shows a sentiment reading derived from how a voice sounded or how a face looked, ask which article of which regulation they think permits it in a workplace, and ask for the answer in writing. If a vendor derives a mood label from typing speed, meeting density, or message volume, ask the same question about the inference itself rather than about the input.

• Emotion inference in the workplace is prohibited conduct under EU AI Act Article 5(1)(f), with narrow medical and safety exceptions.
• A privacy notice does not convert prohibited inference into permitted inference.
• Ask where a state claim comes from: a sentence the person wrote, or a trace they left.
• Ask whether the vendor will put its answer in the contract rather than the deck.

What changes when the person authors the input

A check-in that a person writes for themselves changes the failure modes rather than removing them. The obvious cost is coverage: people write on the days they write, and silence is not data. The obvious benefit is that every claim has a receipt. When a read says a theme keeps returning, the days behind it can be opened, and the person can mark it accurate, say it lacks context, say it is not relevant, or dismiss it.

The second change is what the organization is entitled to. If the input belongs to the person, the organizational view has to be a byproduct, gated on group size, and stripped of anything that names an individual. That is a harder product to build than a dashboard that lists people by risk, and it is the version a workforce keeps using once the novelty passes.

The third change is the one buyers underestimate. A share-first tool cannot tell you who is burning out, and it should not pretend otherwise. What it can tell you is that a particular stretch of work kept producing the same theme across enough people to publish, which is a fact about the work rather than a verdict about anybody in it.

What an organization can act on without watching anyone

The useful organizational output in this category is a statement about work: a stretch of weeks, a shift pattern, a handover, a staffing gap, a recurring theme in a group large enough to report on. Those are conditions a leader can change. A person-level strain score is not a condition anyone can change, and it arrives with an implicit instruction to do something about a person.

This is also the grammar that keeps a workplace program on the right side of works-council co-determination in Germany under BetrVG 87(1)(6) and of the medical-inquiry limits in ADA 12112(d)(4) in the United States. A vendor that promises an employer insight into employees is making a different promise, legally, from a vendor that gives an employer aggregate signal about work. The words are not decoration.

A good test before you buy: write the sentence you expect to read on the dashboard in month three. If the sentence has a person in the subject seat, the product is doing the first job. If it has a work condition in the subject seat, it is doing the second.

• Name the work condition the output is supposed to inform.
• Name the leader who can change that condition.
• Name the group size at which the output is allowed to appear.
• Name what happens to the output when the group falls below that size.
• Name the employment decisions the output may never inform.

Where thresholds fit, in brief

Every share-first program depends on a suppression rule, because an aggregate over four people in a nine-person team is not really an aggregate. Published minimums vary widely across this category, and the full cross-vendor comparison lives in a separate guide rather than being summarized loosely here.

The short version for this page: Microsoft publishes the fullest table, including the line that the minimum threshold for an identifiable Employee Lifecycle or always-on survey is one. Lattice publishes a floor of three for anonymous engagement and pulse surveys that admins may raise but never lower, and states that onboarding and exit surveys are identifiable. Leapsome publishes a default anonymity threshold of three that admins set. Culture Amp states its minimum reporting group size is usually 5, but that it may vary depending on the exact circumstances.

Daylogue publishes its own ladder: themes at 5 people, averages at 10, and some protected settings at fifteen or a higher configured floor. Thresholds reduce reidentification risk; they do not make it impossible. A small team, a rare role, or an unusual week can still make a group recognizable, and a program that has not planned for that has planned only for the easy case.

Seven questions that separate the two designs

Feature lists will not tell you which design you are buying, because both use the same vocabulary. These questions will, and each one has a right answer that a vendor can put in writing.

1. 1

   Where does a state claim come from?

   Ask whether any claim about how a person feels is derived from something they wrote or said, or from behavior, activity, tone, or physiology. Ask for the answer per feature, not per product.

2. 2

   What is the product licensed to ingest?

   Read the product terms rather than the product page. A licensed data type is not proof that anyone ingests it, and it is also not something you want to discover after signature.

3. 3

   Which capabilities are in preview?

   Ask which features are generally available, which are preview, and which require the vendor to enable them for your tenant. Plan around what ships.

4. 4

   What is the published minimum group size?

   Ask for the number, whether an administrator can lower it, and what happens to the output when a group falls below it.

5. 5

   Which programs are identifiable?

   Ask which survey or program types are identifiable rather than confidential, and ask for the documentation page that says so.

6. 6

   Who can export what?

   Ask which roles can export, whether exports carry manager, department, or other attributes alongside answers, and who authorizes turning an export on.

7. 7

   What may the output never be used for?

   Get the prohibition on hiring, promotion, evaluation, compensation, scheduling, discipline, and termination into the contract, covering derived material and not only visible text.

How Daylogue sits on this line

Daylogue is a system for self-understanding, and pattern journaling is how it reads you. A person checks in for about two minutes, typed or spoken, on their own days. Over weeks the app reads what they wrote and shows them what keeps returning. Their stress running higher on the nights they logged under six hours, for one, taken off the check-in itself rather than a wearable. Every read carries the days behind it, so it can be opened, argued with, or thrown out.

Daylogue takes in what you write, what you say, what your week looks like, and what your body’s doing, and finds the connections between them. It works from what people choose to share and does not infer emotion from faces, voice tone, or physiology. Imported health records may be used as factual context but not as emotion labels. There is no strain score, no risk list, and no person-level verdict, because none of those is a thing a person can inspect and correct.

The organization receives aggregate signal about work. Employer-context dashboards are designed not to display individual entries, transcripts, scores, or participation histories, and eligible aggregate views appear only after the applicable threshold is met. Thresholds reduce reidentification risk; they do not make it impossible, and a program that says otherwise is overselling a real control.

The honest limits: Daylogue is not therapy and is not a replacement for professional care. It is not a coaching service or an HR tool. It cannot tell you who is burning out, it needs weeks of check-ins before a personal read is worth much, and it needs enough participants in a group before an organization sees anything at all. Those constraints are the design, not a roadmap gap.