NeuraBloomNISAF · The developing framework
The NeuraBloom Individualized Software Adaptation Framework is a repeatable engineering process for Individualized Software Adaptation. Requirements vary from learner to learner; the process for translating, testing, and refining them stays consistent.
Create a Learner Technology Profile.
Translate family knowledge and authorized team input into software requirements: how the learner accesses, understands, and responds to an activity.
For example: Record a preference for spoken instructions and large touch targets.
Define the Target Skill Object.
Describe the team-identified learning target, the task, the expected response, and the activity conditions. The specialist translates an existing educational goal into an implementable activity; they do not determine the goal.
For example: Represent answering a ‘where’ question as a choice among illustrated locations.
Apply the Interface Adaptation Matrix.
Map access requirements to controlled settings for presentation, interaction, cognitive load, and pacing. Make interface decisions explicit so they can be reviewed and changed.
For example: Compare three large visual choices with six written choices.
Run a consistent activity loop.
Prompt → Stimulus → Response → Feedback → Reinforcement → Next Trial. Keep the sequence predictable while adapting what each step looks and sounds like.
For example: Present a spoken passage, invite a selection, and provide clear feedback before continuing.
Apply standardized adaptive support and prompting rules.
Specify when to offer a visual cue, repeat an instruction, simplify the display, or pause. Repeated incorrect attempts should prompt a review of support rather than endless drilling.
For example: Offer a visual prompt after an unsuccessful attempt, with an option to take a break.
Capture relevant performance, access, and engagement data.
Define the information needed to understand the experience, such as task responses, prompt use, missed selections, and session length. Interpret usage information alongside family and team observations.
For example: Record whether an answer followed a prompt and whether a selection needed another attempt.
Review Performance + Access + Engagement.
Consider the three dimensions together to distinguish task difficulty from an interface barrier or an experience that is hard to stay involved in. The specialist evaluates the software experience, not the child.
For example: A wrong answer alone cannot tell us whether the text was understood or the button was hard to select.
Change controlled software variables and repeat.
Adjust a defined setting, document the change, and revisit the activity. Keep the learning target stable where appropriate so the team can understand what the software change made possible.
For example: Change button size, re-test access, and review before changing another variable.
Infographic coming soon. The full framework is available as text on this page.
Stage 07 · Evaluate
Can the learner complete the task?
Is performance on the targeted skill improving?
Can the learner successfully interact with the software?
Could the interface itself be creating a barrier?
Will the learner remain involved?
What encourages continued participation?
We evaluate the software experience, not the child.
Stage 01 · Profile
The Learner Technology Profile records what software needs to support. It is not a psychological, medical, diagnostic, or educational evaluation. Possible categories include:
Stages 03 + 08 · Interface and Adapt
Adaptations are explicit software choices. Select relevant variables, document their settings, and review changes against the same target activity.
Stage 06 · Instrument
A standard capture plan should define each event before an activity runs. Record only information relevant to reviewing Performance, Access, and Engagement, with appropriate authorization.
Activity and configuration version, target, start and end times, and whether the session was completed or paused.
Presented stimulus, response method, response, prompt level, and timing. Distinguish supported responses from independent ones.
Observable pauses, retries, and exits alongside authorized family or team observations. An event alone does not explain why it happened.
Engineering architecture
These are proposed architecture concepts for the developing framework, not a claim that every tool implements this data model. They separate learner requirements, activity configuration, interaction records, and subsequent changes.
LearnerProfileSkillTargetInterfaceProfileActivityTemplatePromptStrategySessionTrialEngagementEventAdaptationA LearnerProfile informs an InterfaceProfile and PromptStrategy. A SkillTarget configures an ActivityTemplate. A Session groups Trials and EngagementEvents; review of those records can inform a documented Adaptation.
Return to observation after each refinement. Family and authorized team feedback help interpret what the usage information can—and cannot—tell us about the software experience.
NeuraBloom Consulting is a developing service. Get in touch to discuss your questions and explore whether software adaptation could be a fit.
Ask about Consulting