scholexis

From conditions to application behavior

What Scholexis understands about diagnosed neurodivergent conditions, how that changes the application, and which functions are built today.

Scholexis maps conditions a student experiences to concrete application behavior. The current source-of-truth map contains 24 conditions, 93 feature listings, and 76 distinct functions. Every listing is tracked as built, partial, unbuilt, or still unverified.

A condition name beside a generic feature is not enough. Each mapping must show that we understand the condition’s failure mechanism and that we understand how software should behave differently because of it.

Task hesitancy

What we understand: Starting costs more than doing. The most overdue item may have the highest activation cost precisely because it has become so loaded.

How the app changes: Work can be broken into editable steps with a first action small enough to begin. Start here considers startability before urgency rather than permanently serving the oldest failure.

Built today: Break this into steps. Startability-based selection is partially implemented and identified as such in the internal status map.

Time blindness

What we understand: This is estimation failure, not merely ignorance of calendar dates. A system that estimates on the student’s behalf and never checks itself remains confidently wrong.

How the app changes: Work appears as a proportional shape. Where minutes are known, they are shown. Future defaults quietly adjust from actual-versus-estimated outcomes rather than grading the student on accuracy.

Built today: Show time as a shape. Learn how long things take me.

Limited energy

What we understand: Capacity changes by day. A plan built to theoretical maximum capacity becomes another failure rather than support.

How the app changes: Work is priced in experienced cost. The student can say today is a low day, and the visible work responds to current capacity.

Built today: Price everything in what it costs me. Warn me before I spend it. Let me say today is a low day. Fit-today selection remains partial.

Interruption cost

What we understand: An interruption may end the work rather than pause it. Returning requires reconstructing context and making the same decision again.

How the app changes: The application preserves where the student stopped, what was happening, and what comes next. A one-action note carries that context forward.

Built today: Tell me what I was doing and what was next. Let me leave myself a note in one action. The full handoff remains partial.

Asking is the hard part

What we understand: The social judgment and language of a request may cost more than the underlying need. The student may know what they need and still be unable to initiate the ask.

How the app changes: Scholexis drafts extension, accessibility, and disclosure language the student reviews and sends. Scholexis never sends it.

Built today: Draft it for me and let me send it.

Demand avoidance

What we understand: Being told to — even by oneself — can create resistance. An imperative reminder may intensify the barrier it is meant to solve.

How the app changes: Reminder language describes rather than commands. The application offers options and provides one master switch that stops all suggesting.

Built today: Never notify me with an instruction. Give me options, not a next step. Let me turn off everything at once.

Masking and supporter access

What we understand: Appearing fine hides the cost. Broad visibility can reward performance and turn support into surveillance, which makes honest data less likely.

How the app changes: Supporters may see plans only when the student grants access. They do not receive grades, accommodations, energy check-ins, focus history, or reflections.

Built today: Nobody sees how I’m doing. Nothing leaves without me choosing it.


Every other built function

The following are also built and working today:

Getting started and capturing work

What the app is allowed to say

Reading and representation

There is more that is partial or unbuilt, and we do not present it as complete. The point of the map is not to manufacture a long feature list. It is to preserve the chain from a condition we understand to application behavior we can verify.