1. The tool tax

Executive function is the set of processes that turn intention into action: holding goals in mind, sequencing steps, initiating tasks, sustaining attention, and adjusting when circumstances change. Every productivity tool implicitly asks the user to spend some of this capacity on the tool itself: setting it up, updating it, remembering to check it, reconciling it with the other tools. We call this the tool tax.

For people with abundant executive capacity, the tax is affordable. For people whose executive capacity is precisely the constrained resource, it is regressive: the tools demand the most from those with the least to spend. Abandoned task managers and elaborate systems that lasted eleven days are not evidence of insufficient discipline. They are evidence of a tax the design imposed.

2. Five design principles

2.1 Reduce load before adding capability

The first question for any feature is not “what does this let the person do?” but “what does this stop the person having to hold in their head?” A system that remembers context, resurfaces commitments at the relevant moment, and carries state across days is doing executive work so the person does not have to.

2.2 Externalize state

Much executive difficulty is working-memory difficulty: keeping the plan, the progress, and the next step simultaneously in mind. Systems should hold that state visibly and reliably, so returning to a task after an interruption means reading, not reconstructing.

2.3 Make the next action smaller

Task initiation often fails at the size of the first step. A system that can decompose “prepare the report” into “open last quarter's file” changes the activation cost of starting. The unit of support is not the project or the task but the next concrete action.

Abandoned task managers are not evidence of insufficient discipline. They are evidence of a tax the design imposed.

2.4 Treat inconsistency as data

Human effort is variable, and systems that assume linear daily progress convert ordinary variability into a backlog of guilt: badges lost, streaks broken, red overdue labels multiplying. A supportive system treats a difficult week as information about conditions, not as a verdict about character, and adjusts scaffolding accordingly.

2.5 Preserve agency

Support is not substitution. The person decides what matters, what to commit to, and when to override every suggestion. A system that quietly starts making decisions for the person has stopped scaffolding executive function and started replacing it. That is a different product, and not the one we think should be built.

3. What this rules out

These principles exclude some familiar patterns: engagement mechanics that manufacture urgency, shame-based streaks, notification volumes calibrated to attention capture rather than usefulness, and automation that acts without a mandate. They also exclude the assumption, embedded in most defaults, that there is one right way to organize a day.

Key observations

1. Executive support is subtractive first. The primary value is cognitive load removed, not features added.
2. Working memory is the bottleneck. Externalized, trustworthy state changes what a person can return to after interruption.
3. Initiation is a step-size problem. Decomposition to the next concrete action lowers the cost of starting.
4. Variability is normal. Systems should absorb difficult weeks rather than penalize them.
5. Agency is the boundary. Scaffolding that starts deciding for the person is no longer scaffolding.

Limitations

This is a design perspective. It reports no experiments, participants, or outcome data, and it has not undergone peer review. The five principles are commitments we consider well-motivated by the structure of the problem and by the documented shortcomings of load-adding tools; whether systems built on them measurably improve follow-through is an empirical question that our ongoing development and testing is intended to examine.

Suggested citation

Axiom Labs Research (2026). Designing AI Systems for Executive Function Support. Research Perspective. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/designing-ai-systems-for-executive-function-support.html

1. Why unexplained support becomes control

A recommendation the recipient cannot interrogate offers two options: comply or ignore. Neither is a decision in any rich sense. Evaluation requires access to reasons: what the suggestion was based on, what it weighed, what would have changed it. Withhold the reasons and the human's role degrades from judge to switch.

This matters most exactly where AI support is most valuable: consequential, personal, cross-domain decisions. The more a system knows about a person's patterns, the more plausible its suggestions sound, and the less able the person is to push back without reasons in hand. Opacity plus intimacy is an uncomfortable combination.

2. What counts as an explanation

Not every output labeled “explanation” earns the term. A useful standard is that an explanation should let the person answer three questions: What was this based on? (the inputs that mattered), Why this rather than something else? (the reasoning or trade-off), and What would change it? (the sensitivity). Explanations should be faithful to the system's actual behavior. A plausible story that does not reflect the real basis of the output is decoration, and worse than silence because it manufactures unearned trust.

Withhold the reasons, and the human's role degrades from judge to switch.

3. What the requirement demands from architecture

Treating explainability as a requirement changes engineering decisions that are difficult to revisit later. It constrains model and pipeline choices toward designs whose outputs can be traced to inputs. It requires provenance: keeping track of which data influenced which conclusion. It shapes interfaces, because explanations need a place to live at the moment of the suggestion, not in a report nobody opens. And it forces honesty about confidence: a system that must show its reasoning must also show its uncertainty.

These constraints have costs, and acknowledging them is part of the argument. Some techniques are harder to deploy under a traceability requirement; some explanations add interface weight. We think the costs are the price of admission for systems that participate in consequential decisions, and that they are far cheaper paid at design time than retrofitted after trust has been spent.

Key observations

1. Reasons enable decisions. Without access to the basis of a suggestion, a person can only comply or ignore.
2. Opacity plus intimacy compounds. The more personal the system, the more explanation matters.
3. Three questions define an explanation. What was it based on, why this, and what would change it.
4. Faithfulness over plausibility. An explanation that misrepresents the system's actual basis manufactures unearned trust.
5. Requirements shape foundations. Traceability and provenance are architectural choices, cheap early and expensive late.

Limitations

This is a position piece on product and architecture priorities. It reports no user studies or measurements of explanation effectiveness and has not undergone peer review. The claim that faithful explanations improve decision quality and trust calibration is supported in the broader research literature to varying degrees across contexts; how these effects play out in any specific product is an empirical question requiring evaluation in that product.

Suggested citation

Axiom Labs Research (2026). Explainability as a Product Requirement, Not a Feature. Research Perspective. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/explainability-as-a-product-requirement.html

1. The snapshot problem

Consider two people whose data looks identical today: elevated stress, low activity, missed commitments. For one, this is a stable long-run pattern; for the other, it is a sharp two-week departure from years of steadiness. A snapshot cannot tell them apart, yet almost everything about the right response differs: what to suggest, how urgently, and what a return to normal would even mean.

Systems that see only the present are forced to respond to the average case. Personalization built on snapshots is therefore shallower than it appears: it may address the current input, but it cannot address the person.

2. Four kinds of longitudinal context

Baselines. “High” and “low” are personal. Six hours of sleep is depletion for one person and routine for another; meaning comes from deviation from an individual's own history, not from population norms.

Trajectories. Direction often matters more than position. Slightly-below-average and improving is a different situation from slightly-above-average and declining, and support should distinguish them.

Cycles. Weeks, months, seasons, billing periods, school terms: much of life is periodic. A system aware of a person's cycles can distinguish a recurring dip from a novel one.

Response history. What happened the last time this person tried the suggested change? Support that remembers which adjustments actually helped this individual, and which repeatedly failed, stops recycling advice that history has already answered.

Personalization built on snapshots may address the current input, but it cannot address the person.

3. The responsibility that follows

Longitudinal context requires longitudinal retention, and retention is not free of obligation. In our view a system that keeps history owes its user four things: transparency about what is retained, control including meaningful deletion, purpose limitation so history serves the person's goals rather than third-party ones, and proportionality: keeping what supports the person, not everything that can be kept. A long memory without these commitments is a liability wearing the costume of a feature.

Key observations

1. Identical snapshots, different people. Present-state data cannot distinguish a stable pattern from an acute departure.
2. Meaning is deviation from self. Personal baselines outperform population norms as reference points.
3. Direction beats position. Trajectory and cycle awareness change the interpretation of the same reading.
4. History answers repeat advice. Response history prevents recycling suggestions that already failed for this person.
5. Retention creates obligation. Transparency, control, purpose limitation, and proportionality are the price of memory.

Limitations

This is a short research note stating a design position. It presents no datasets, experiments, or statistical results and has not undergone peer review. The claim that longitudinal context improves decision support is, in its general form, well-motivated; the specific magnitude of benefit in any product is an empirical question requiring testing and validation.

Suggested citation

Axiom Labs Research (2026). The Role of Longitudinal Context in Personalized Decision Support. Research Note. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/longitudinal-context-in-personalized-decision-support.html

1. Fragmented measurement, fragmented pictures

Coordination failures in care are usually described as communication failures, and often they are. But beneath many of them sits a measurement problem: the services involved are not measuring the same things, over the same periods, against the same goals. When a therapist's notes, a case manager's plan, and a program's attendance records each use their own categories and cadence, even perfect communication transmits fragments.

The costs are familiar to practitioners. Progress in one setting is invisible in another. Regressions are noticed late because no single view had enough signal. People repeat their history to every new provider. And the person at the center, or their family, becomes the unpaid integrator of record, carrying information between professionals in memory and folders.

2. Three properties of coordinated measurement

2.1 Shared goals

Coordination begins with agreeing on what progress means. That requires goals stated in terms meaningful to the person and legible to every service, not a lowest common denominator, but an explicit mapping between each service's objectives and the person's own priorities. A goal no one shares cannot be coordinated toward.

2.2 Aligned timelines

Services review progress on different cycles: weekly sessions, quarterly plans, annual reviews. Coordinated measurement places observations on one shared timeline, so that a change in one domain can be seen alongside what was happening in the others. Alignment in time is what turns parallel records into a joint picture.

2.3 Transparent progress signals

Every participant, including the person and, where appropriate, their family, should be able to see the same progress signals and understand where they come from. Transparency here is not a courtesy; it is what makes the measurement trustworthy enough to act on, and it keeps the person a participant in their own care rather than its subject.

The person at the center becomes the unpaid integrator of record, carrying information between professionals in memory and folders.

3. The boundary that makes it safe

Coordinated measurement is decision support, not decision making. Signals can show that attendance shifted, that a goal stalled, that patterns across settings moved together. What those movements mean for this person, and what should change in response, is professional and personal judgment. Systems in this space should be designed to make qualified professionals better informed, never to generate diagnoses, treatment decisions, or clinical conclusions. Wherever regulation applies to a deployment context, conformance is a precondition, not an aspiration.

Key observations

1. Coordination failures are often measurement failures. Services that measure different things on different cycles transmit fragments even when they communicate well.
2. The integrator is usually unpaid. Fragmentation shifts the work of assembling the picture onto the person and their family.
3. Shared goals precede shared data. Without an agreed definition of progress, aligned records still do not coordinate.
4. Time is the join key. A shared timeline is what turns parallel notes into a joint picture.
5. Signals inform; professionals decide. Measurement systems in care must support judgment, not replace it.

Limitations

This is a conceptual perspective grounded in the widely documented structure of multi-service care; it reports no study, site data, or outcome measurements of our own, and it has not undergone peer review. Claims about what coordinated measurement would improve are design hypotheses. Any system operating in care settings would additionally require conformance with the privacy, consent, and professional-practice requirements of its jurisdiction, which this piece does not analyze.

Suggested citation

Axiom Labs Research (2026). Measuring What Matters in Care Coordination. Research Perspective. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/measuring-what-matters-in-care-coordination.html

1. Defaults are a theory of the user

Every metric embeds assumptions. A daily streak assumes that consistency-by-calendar-day is the meaningful unit of commitment. A focus score built on long unbroken sessions assumes that sustained continuous attention is what good work looks like. A productivity graph that rewards even output assumes that effort is naturally uniform. None of these assumptions is neutral; each is a theory of how people work.

For people whose cognition matches the theory, the metrics feel like mirrors. For people whose attention comes in intense bursts, whose energy follows longer cycles, whose deep work happens in hyperfocus sessions at irregular hours, the same metrics return a steady verdict of deficiency, not because less was accomplished, but because the accomplishment had the wrong shape.

The metrics return a verdict of deficiency, not because less was accomplished, but because the accomplishment had the wrong shape.

2. Four properties of respectful measurement

2.1 Personal reference frames

Comparison against one's own history, not against a population default. The question a supportive system asks is “how is this week relative to your patterns?” and not “how do you compare to the imagined average user?”

2.2 Flexible rhythm

The unit of consistency should be adjustable: a week, a cycle, a project arc. Burst-and-recover patterns are patterns, and a system that can only see days will misread them as chaos.

2.3 Multiple definitions of progress

Output volume is one definition. Others include reduced friction, sustained wellbeing, fewer abandoned commitments, or progress on the one thing that mattered most. The person, not the default dashboard, should decide which definition their system optimizes for.

2.4 Non-punitive variability

Broken streaks, red overdue badges, and guilt-inflected notifications convert variability into shame. Measurement that respects cognitive difference treats a divergent week as information (possibly about workload, health, or season) and responds by adapting, not scolding.

3. Design for difference is design for everyone

These properties are motivated by neurodivergent experience, but they are not niche accommodations. Everyone's capacity varies, through illness, caregiving, grief, and ordinary life. Metrics that can only praise uniformity misread every human being some of the time; they simply misread some people all of the time. Building measurement around personal frames and flexible definitions of progress is not a special mode. It is the correction of a defect that standardization normalized.

Key observations

1. Metrics are theories. Streaks, focus scores, and uniform-output graphs encode assumptions about how people work.
2. Misfit reads as deficiency. Non-standard patterns are scored as failure even when outcomes are strong.
3. Self-reference over population norms. Personal baselines are the respectful comparison frame.
4. Progress needs a chooser. The person should select which definition of progress their measurement serves.
5. Accommodation generalizes. Designing for cognitive difference fixes failures that affect everyone sometimes.

Limitations

This is a conceptual perspective. It reports no participant studies or quantitative findings of our own and has not undergone peer review; it draws on the extensive public discussion of neurodivergent experience with productivity tooling and on analysis of the assumptions embedded in common metrics. Whether the four proposed properties measurably improve outcomes for neurodivergent users is an empirical question our development and testing is intended to explore, and nothing here should be read as clinical guidance.

Suggested citation

Axiom Labs Research (2026). Neurodiversity and the Limits of One-Size-Fits-All Metrics. Research Perspective. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/neurodiversity-and-the-limits-of-one-size-fits-all-metrics.html

1. The boundary

Consider a system that notices task completion falling for two weeks alongside shorter sleep. That correlation is a signal: a genuine, checkable fact about recorded data. “You are burning out” is a conclusion. “You should cut back your commitments” is a further conclusion built on the first. Between the signal and the conclusions sits everything the system does not know: the deadline that ends on Friday, the new baby, the deliberate sprint, the recovery already underway.

The boundary, stated plainly: a system may report what the data shows, how it compares to the person's own history, and what tends to co-occur. Deciding what it means and what to do about it belongs to the person, or, in professional contexts, to the person and the qualified professionals working with them.

A pattern in the data is a fact about the data. What it means for a specific person is a judgment the data alone cannot settle.

2. Why systems drift across it

Drift is the default because conclusions feel like value. “You are stressed” sounds more helpful than “three indicators departed from your baseline this week,” and product pressure pushes toward the confident sentence. Interfaces compress nuance; summaries shed qualifiers; and each small compression moves the system from reporting toward diagnosing. No one decides to cross the boundary. It is crossed by a hundred reasonable-sounding shortcuts.

3. Holding the line in practice

Designing to the boundary means concrete habits: phrasing outputs as observations with reference points rather than verdicts; distinguishing correlation from cause in the interface, not just the fine print; presenting alternatives (“this pattern can accompany schedule changes, illness, or increased load”) instead of single stories; and asking rather than asserting when context is missing. In care and professional settings it also means something stronger: signals are inputs to qualified judgment, never substitutes for it.

Held consistently, the boundary is not a limitation on usefulness. It is what makes the useful parts trustworthy: a system that refuses to pretend it knows what things mean is a system whose factual reports can be believed.

Key observations

1. Signals are checkable; conclusions are contextual. The data supports the former; only the person's context completes the latter.
2. Drift is the default. Product pressure toward confident sentences crosses the boundary one shortcut at a time.
3. Phrasing is policy. Observations with reference points, alternatives, and questions keep interpretation with the person.
4. Professional contexts raise the bar. In care settings, signals inform qualified judgment and never replace it.
5. Restraint purchases trust. Refusing to overclaim is what makes the system's factual reports believable.

Limitations

This is a brief research note stating a design position, without empirical study or peer review. The boundary described here is a normative commitment about how systems should behave, defended by argument rather than data; readers should weigh it as such.

Suggested citation

Axiom Labs Research (2026). Signals Are Not Conclusions: A Note on Interpretation Boundaries. Research Note. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/signals-are-not-conclusions.html

1. The measurement we have

Most of the tools that measure human life measure one slice of it. A fitness tracker counts steps and sleep. A budgeting application categorizes spending. A project tool counts completed tasks. A care plan tracks progress toward service goals. Each of these is genuinely useful within its slice, and each was built by people who understood that slice well.

The difficulty is that the person being measured is not sliced. The same individual who slept badly is the one whose task completion dropped, whose spending drifted, and whose therapy appointment was missed. From inside any single tool, each of those looks like an isolated fluctuation. From the person's perspective, they may be one event with five shadows.

This is not a criticism of single-domain tools. It is an observation about what they structurally cannot see. A measurement system inherits the boundaries of the data it collects, and when those boundaries follow institutional lines (health here, work there, money elsewhere), the measurements follow them too.

The person being measured is not sliced. Many of the most decision-relevant patterns exist between domains, not within them.

2. What falls between the slices

Consider the kinds of questions that people and the professionals supporting them actually ask. Is the new routine holding up under work pressure? Did the financial stress precede the sleep disruption, or follow it? Is progress on one goal being purchased at the expense of another? Which supports, when present, coincide with better follow-through?

None of these questions live inside one domain. Each is a question about a relationship between domains, and relationship questions are exactly what siloed measurement cannot answer, because the relevant signals are recorded in systems that do not share timelines, identifiers, or context.¹

3. Requirements for multidomain models

If cross-domain relationships are where much of the useful signal lives, what would a measurement model need in order to represent them? We propose four requirements. They are conceptual commitments rather than a finished architecture, but each has direct design consequences.

3.1 Shared temporal structure

Cross-domain relationships are almost always temporal: something in one domain precedes, coincides with, or follows something in another. Data recorded on incompatible timelines (daily in one system, per-visit in another, per-transaction in a third) must be brought into a shared temporal structure before relationships can even be represented, let alone examined.

3.2 Preserved context

A signal separated from its context invites misreading. "Missed workout" means one thing in a week of illness and another in a month of drift. Multidomain models must carry provenance and circumstance alongside values, not because context makes analysis tidy (it doesn't), but because stripped-down signals produce confident and wrong interpretations.

3.3 Person-defined goals

Progress is progress toward something, and the something differs by person. Models that import universal definitions of progress (more steps, more output, more savings) measure conformity to a template rather than movement toward a person's own goals. The reference frame must belong to the person being measured, or to the person and the professionals supporting them, working together.

3.4 Interpretive boundaries

Finally, and most importantly: a multidomain model can surface a relationship; it cannot know what that relationship means for a particular life. The boundary between surfacing patterns and drawing conclusions must be built into the system. Patterns belong to the model. Conclusions belong to people.²

Comparing the two approaches

The final row deserves emphasis. Multidomain measurement does not simply remove the weaknesses of siloed measurement; it trades them for different ones. A system that connects more of a person's life can misread more of it, and holds more sensitive information while doing so. That trade is only worth making with strong interpretive boundaries and privacy-conscious architecture, which is why we treat those as requirements rather than enhancements.

Section 4Key observations

1. Decision-relevant patterns concentrate between domains. The questions people and professionals actually ask are predominantly relationship questions that single-domain tools cannot represent.
2. Connection without context is dangerous. Linking domains while discarding provenance produces confident misreadings at larger scale.
3. The reference frame must be person-defined. Universal progress templates measure conformity, not progress.
4. Interpretation is a human function. The most important design decision in a multidomain system is where it stops.

Limitations

This is a conceptual perspective. It reports no experiments, datasets, participants, or statistical findings, and it has not undergone peer review. The four requirements proposed here are design commitments derived from analysis of existing measurement practice; whether systems built on them deliver measurably better support is an empirical question our ongoing product development is intended to test. Readers should treat this piece as a framework for thinking, not as evidence.

Implications

For builders of measurement systems, the implication is architectural: shared temporal structure, context preservation, person-defined goals, and interpretive boundaries are difficult to retrofit, so they belong in the foundation. For professionals who use measurement in their work, the implication is interpretive: a cross-domain pattern is a prompt for a conversation, not a verdict. And for the broader field, the implication is a research agenda: the interesting questions about human progress are relationship questions, and our instruments should finally be able to represent them.

Suggested citation

Axiom Labs Research (2026). Toward Multidomain Models of Human Progress. Research Perspective. Axiom Labs Technologies. https://axiomlabstechnologies.com/research/toward-multidomain-models-of-human-progress.html