Designing for Trust Before Disclosure: Family-Centered AI in Special Education

Abstract

Artificial intelligence tools in education are evaluated largely by what they produce: accurate summaries, stronger goals, more readable language, faster documentation. Less attention has been paid to what must happen before families are willing to hand such a system a consequential educational record in the first place.

This report describes design knowledge from building and deploying Expert IEP, a family-centered artificial intelligence platform that helps families interpret and act on Individualized Education Programs. It draws on iterative development with families using the product under the conditions it was built for. Expert IEP has supported more than 4,800 families since 2022.

Three design cases are examined. The first concerns onboarding, where the sequence of asking families for a sensitive document was reconsidered around what a family needs to understand before disclosure is reasonable. The second concerns data governance, where the platform's public commitments distinguish information necessary for educational interpretation from information the system declines to retain, including behavioral and disciplinary history. The third concerns workflow, where family feedback exposed a mismatch between a mobile-first design and where families actually keep educational records.

The central proposition running through all three is that a system should not claim authority its evidence cannot support. Some properties of an educational record leave observable textual traces and can be examined computationally. Whether the child in that record is the child a family knows cannot be established from the record at all. Increasing model capability does not change this.

The report proposes six design principles for high-stakes family-facing educational AI. These principles are offered as translational design knowledge generated through deployment, not as experimentally validated rules. Proprietary model orchestration, prompts, scoring logic, and implementation details are outside the report's scope.

1. The Problem Is Not Whether the Model Works

Most evaluations of educational artificial intelligence begin after the user has already agreed to use the system. The model receives an input. Its output is judged for accuracy, quality, efficiency, or alignment with a rubric.

Those questions matter. They are not sufficient for systems that ask families to disclose records about their children.

An Individualized Education Program can contain educational evaluations, disability classifications, academic performance data, behavioral observations, service histories, goals, accommodations, and family concerns. For a family-facing system, obtaining that document is not a neutral upload step. It is an act of disclosure, and the family is the one bearing its consequences.

Expert IEP was built around a practical question: what does an artificial intelligence system have to do before a family is willing to trust it with that information?

The answer did not come from a controlled usability study. It developed through repeated interaction with families using the product in the circumstances it was built for. Features shipped, families responded, friction became visible, assumptions were revised, and the system changed.

This report documents what that process produced. It is not a description of Expert IEP's architecture, and it discloses no prompts, orchestration logic, scoring thresholds, or internal taxonomies. It documents design knowledge: what problems became visible, how they were interpreted, what changed in response, and what principles those changes suggest for family-facing artificial intelligence.

2. What the System Is For

Expert IEP supports families navigating special education documentation and decision-making. Its development sits between learning sciences, computational text analysis, family knowledge, disability, and educational technology.

It was not built on the premise that artificial intelligence should replace family or professional judgment. Its purpose is narrower: to make information in educational records more interpretable and actionable, and to help families identify questions and concerns worth raising.

That boundary hardened as the system developed.

A model can identify linguistic patterns in a document. It can surface technical terminology, reorganize information, and generate questions. It cannot determine whether the child represented in an institutional record is the child a family knows. It cannot decide whether a professional observation should outweigh a family's longitudinal experience. And it should not acquire authority merely because its output was computationally produced.

Operating principle: a system can support interpretation without assuming epistemic authority over the family.

3. Evidence Base and Scope

The cases in this report come from product development and real-world deployment rather than from a prospective research protocol. The evidence base includes family feedback, support interactions, observed points of friction in product use, design-change records, product usage patterns where available, and public operating commitments adopted during deployment.

The cases are therefore not presented as estimates of how frequently a particular problem occurs across all families, nor as evidence that a specific design change caused a particular behavioral outcome. The report does not make comparative or causal claims about onboarding sequences, privacy practices, or workflow changes.

Instead, it uses deployment as a site of design inquiry. When a recurring assumption became visible through family use, the relevant question was whether the assumption was consequential enough to reconsider the system around it. Where product analytics support a descriptive statement, they are identified as such. Where a conclusion comes from feedback, design observation, or an operating decision, it is labeled accordingly.

This distinction matters because commercial deployment can produce knowledge without converting ordinary product activity into experimental research. The aim here is narrower: to make the evidentiary basis of each design proposition visible enough that others can scrutinize, challenge, compare, and eventually test it.

4. Design Case I: Trust Before Disclosure

The clearest early lesson came from onboarding.

The original sequence asked families for the educational document before the system had demonstrated much of anything. A conventional product reading would treat departure at that point as funnel abandonment: find the friction, reduce it, raise conversion.

That reading was inadequate for the context.

Families were being asked to hand a sensitive record about their child to an AI-supported system they had just met. The question was not whether the upload flow was easy. It was whether enough had happened to justify proceeding.

The onboarding experience was therefore rebuilt around a different design question:

What does a family need to understand or experience before being asked to entrust the system with the document?

The revised sequence provides interpretive value earlier, makes clearer what the system does and does not do, and surfaces aspects of documentary complexity that families may recognize from their own experience with special education language before moving further into the workflow. The computational weighting and scoring behind those steps remain proprietary. The design lesson does not.

Principle 1. Demonstrate value before requesting sensitive disclosure.

In high-stakes systems, disclosure should not be the price of discovering whether the technology is useful. The system should establish enough purpose, value, and transparency for the family to make an informed decision about continuing.

A prior demonstration of the same principle

The onboarding redesign was not the first place this logic appeared.

Since September 2024, internal site analytics have consistently identified Expert IEP's plain-language explanation of procedural safeguards under the Individuals with Disabilities Education Act as one of the site's most frequently visited and externally referenced resources. The resource was authored by Expert IEP staff.

The pattern is notable because procedural safeguards are not hidden information. Under IDEA, parents of children receiving special education protections must be provided a procedural safeguards notice in specified circumstances, and the notice is required to explain those rights in understandable language.

The information, in other words, already exists within the system families are navigating.

What families sought out from Expert IEP was an account of those rights in language organized for use.

The observation does not establish why every visitor reached the resource or what each family understood after reading it. It does illustrate the same design principle the onboarding sequence later surfaced from a different direction: access to information and usable access to information are not the same thing.

A resource that asks nothing of a family before giving them something interpretable can establish value before requesting disclosure.

Principle 2. Treat hesitation as evidence.

Abandonment is usually modeled as a performance problem. In sensitive contexts it may also be information.

Unwillingness to continue can reflect uncertainty about privacy, value, system behavior, or what happens to the information being requested. Optimization that simply removes friction can remove evidence of a legitimate concern along with it.

The question is not always how to make the user continue.

Sometimes it is what the refusal is saying about the system that was built.

5. Design Case II: What the System Declines to Know

The second case is the one where the principle is most fully implemented because it exists as a public commitment rather than an internal intention, and because it predates this report.

The commitments described here have been published since August 2025. They were made as operating conditions for the product, not assembled afterward to describe it. That sequence matters for how the report should be read: what follows is an articulation of design logic already in effect.

Expert IEP's Family Privacy Promise states which categories of information are removed from educational documents before analysis and which are retained.

Removed information includes:

• last names and addresses

• medical history and health records beyond the educational diagnosis

• behavioral incident reports and disciplinary history

• family background and personal circumstances

Retained information includes:

• first name

• educational diagnosis

• learning goals and how they are written

• accommodations

• support services

The promise also states what the platform will not do, including selling information, tracking families across sites, building student profiles, sharing information with marketing companies, or retaining information longer than necessary. It identifies family rights to see what information is held, correct it, and delete their account.

The refusal of disciplinary history is the load-bearing choice.

Behavioral and disciplinary records can substantially shape how later readers interpret a child, particularly when an institutional record already contains deficit-oriented descriptions or accounts that the family may dispute. These records can persist across settings and time. For a system whose purpose is to help families interpret an educational plan, retaining an institutional disciplinary history is not necessary to accomplish the core task.

Declining to ingest it is therefore more than a storage decision.

It is a substantive claim about what a computational system should be permitted to know.

Principle 3. Minimize around legitimate need, not technical sufficiency.

Conventional data minimization asks what the least data is that a system needs to function.

A family-centered version asks a different question:

What does this system have a legitimate reason to know about this child?

Those questions can produce different answers.

An educational record contains information that an institution needed, requested, observed, or elected to preserve at some point, for its own purposes and under its own conditions. The presence of an item in the document does not establish that a separate tool assisting the family needs to retain it.

The record's contents are an artifact of institutional history, not a specification of what should travel.

This is the inverse of the question the record itself poses. An institutional record accumulates what institutions need to remember about a child.

A system operating on that record must also decide what it has the right to forget.

A distinction worth stating plainly

Expert IEP does ask families directly about experiences including school discipline through voluntary intake questions that families answer about themselves.

That is different from ingesting disciplinary history from an uploaded institutional record.

The difference is who is deciding.

In the first case, a family chooses to tell the system something and does so in its own interaction with the platform.

In the second, the system takes possession of an institutional account the family may not have authored, may not agree with, may have contested, and may be unable to revise.

The privacy commitment concerns the second.

Learning without identifying

The platform's stated approach to improvement is to track what worked rather than who the student was. Aggregate outcome information can inform future recommendations without making persistent identification of individual students the mechanism by which the system learns.

Stating this as a commitment is not the same as demonstrating it.

A fuller account of how aggregate learning is separated from individual identification, at a level of detail that permits external evaluation without exposing proprietary implementation, is the subject of the second report in this series.

6. Design Case III: The Family's Actual Workflow

A third lesson came directly from families.

Users reported valuing the mobile experience while naming a practical mismatch: educational documents were often stored on a computer rather than on the device they were using. Expert IEP subsequently deployed web-based access alongside mobile.

The problem was mundane and consequential.

The original workflow embodied an assumption about where the document would be when a family wanted help, and family feedback exposed it.

Principle 4. Design around actual workflows rather than assumed users.

Educational technologies are frequently designed around an abstract user completing a clean sequence.

Families do not encounter educational systems that way.

Records may live on a laptop. Meetings happen on another device. A caregiver may be reading an IEP while messaging a teacher, provider, advocate, or relative. Relevant information is distributed across email, portals, paper, conversation, and memory.

A technically sound workflow can still be unusable if it assumes the wrong conditions.

7. Negative Feedback as Design Evidence

Positive feedback establishes that a system is useful to some people under some conditions.

Negative feedback often reveals something different: where the design model may be wrong.

This matters for trustworthiness specifically. A system is not trustworthy because satisfied users say they like it. Trustworthiness also requires mechanisms through which confusion, disagreement, correction, and failure become visible enough to challenge the system.

Principle 5. Build for corrigibility at the output level and the system level.

Families should be able to contest an interpretation the system produces.

Corrigibility must also operate a level higher. When disagreement is repeated or consequential, it should be capable of challenging assumptions built into the product itself.

Negative feedback is therefore not only customer service.

It can become part of the evidence by which the system is evaluated.

8. Bounded Automation

Building this system made visible a line between what is computationally tractable and what requires human knowledge.

Some properties of educational records leave observable textual traces. Technical terminology, sentence complexity, attribution, and particular forms of linguistic positioning can be identified and examined.

Other questions cannot be answered from the document at all.

Whether a record accurately represents a child requires knowledge outside the record.

Whether a family's statement was translated faithfully requires knowing what the family meant.

Whether a description captures meaningful change requires longitudinal and contextual knowledge unavailable from a single institutional artifact.

These are not necessarily deficiencies that a larger model resolves.

They are boundaries of the available evidence.

Principle 6. Do not automate epistemic authority the available data cannot support.

Responsible design requires distinguishing among what a model can detect, what it can reasonably infer, and what only the person whose knowledge is at issue can establish.

Greater model capability does not collapse that distinction.

9. Transparency Without Disclosure of Implementation

Calls for trustworthy AI rightly emphasize transparency. Existing risk-management frameworks similarly emphasize that trustworthiness depends on how AI systems are designed, governed, evaluated, and situated within broader risks to people and organizations.

For commercial systems built on research, however, transparency is sometimes conflated with publishing implementation.

Those are not the same requirement.

A system can be meaningfully transparent without releasing what is required to reproduce it.

Expert IEP's public privacy commitments are one example. The Family Privacy Promise states what categories of information the platform retains and refuses, what the platform says it will not do, and what rights families hold without exposing any part of the platform's proprietary computational architecture.

The workable standard proposed here is whether an external reader can understand:

• what kind of system this is

• what evidence supports its public claims

• what information it uses and refuses

• what its outputs can and cannot establish

• where human-authored frameworks guide computational analysis

• where family judgment remains necessary

• how a family can challenge or correct an output

• what limitations remain

That does not require publishing prompts, orchestration, weighting, thresholds, scoring logic, or architecture.

Transparency about authority, evidence, data practice, and limitations is not equivalent to disclosure of implementation.

10. Six Principles

The deployment cases described in this report produce six design propositions:

1. Demonstrate value before requesting sensitive disclosure.

2. Treat hesitation and abandonment as evidence, not only as conversion problems.

3. Minimize around legitimate need, not technical sufficiency.

4. Design around actual family workflows rather than assumed ones.

5. Build for corrigibility at the output level and the system level.

6. Do not automate epistemic authority the available data cannot support.

These are design propositions generated through deployment, not experimentally validated rules.

That distinction is the point of documenting them.

Once articulated, they become available for scrutiny, comparison, refinement, and testing.

11. What Kind of Knowledge This Is

The line between commercial development and scholarship is not whether a product generated the observation.

The questions that matter are whether the observation is systematically documented, whether its evidentiary source is identified, whether claims remain proportional to the evidence, and whether the resulting knowledge can be used, questioned, or tested beyond the product that generated it.

Expert IEP's development produced design knowledge because deployment repeatedly exposed assumptions that were difficult to see until families interacted with the system.

Those observations do not become experimental findings because they were written down.

Nor should they disappear because they arose during product development.

They are translational design knowledge generated through deployment, and they should be labeled that way.

Prospective research can test what is proposed here. That work might include controlled evaluation of onboarding sequences, systematic analysis of user correction and disagreement, comparison of family workflows across contexts, and evaluation of whether explicit system boundaries affect trust, comprehension, disclosure, and continued use.

The function of this report is to make those propositions available before that research occurs.

Conclusion

Trustworthy educational artificial intelligence cannot be defined only by the quality of what a model produces.

For systems operating on consequential records about children, trust begins earlier.

It depends on whether the system demonstrates enough value to justify disclosure, whether it refuses information it has no legitimate reason to hold, whether its design matches the conditions families actually work in, whether disagreement can change it, and whether its assistance stops where its evidence stops.

Building Expert IEP suggests that some of the most useful information about a system appears not when it performs exactly as intended, but when families hesitate, disagree, leave, return, correct it, or ask it to work differently.

Those moments are easy to classify as noise around the product.

For family-centered AI, they may instead be evidence about the design.

References

Boeckl, K., & Lefkovitz, N. (2020). NIST Privacy Framework: A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0. National Institute of Standards and Technology.

Expert IEP. (2025). Family Privacy Promise.

National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.

Individuals with Disabilities Education Act, 20 U.S.C. § 1415.

Procedural Safeguards Notice, 34 C.F.R. § 300.504.

Forthcoming: Technical Report No. 2, on family-centered data minimization and what computational systems operating on institutional records have the right to forget.