The Data Lake
A school gathers data about a child for one reason: to teach that child better. But a recording, an assessment result and a teacher’s note do not become a useful record simply because they have been collected. They need to belong to the right learner, to the lesson and learning goal that explain them, and to the people allowed to use them. bina is building that connective layer around the school’s own record: dated memberships, registries with a history, transcripts that lead back to a lesson, and working surfaces that read the same facts. The point is not to put everything in one place. It is to keep the context attached as evidence moves from ordinary teaching into a teacher’s workspace, a report or the next tool the school builds.
One record, three rings
The record sits inside two kinds of context. One is the daily life of the school: who taught, which group met, what was submitted and what the family was told. The other is access: the same source can be relevant to several people without giving each of them the same view. The inner path below shows the proposed life of a record, from a source to a corrected, usable view. Select a role on the boundary to see why “shared” does not mean “open”.
Access. teachers: scoped live to the children they teach; sensitive registries hidden by default. family support: their own surface over the assessment registries, meetings and check-ins. school ops: rosters, schedules, placements and level judgments; the role is the grant. leadership: the administration surface plus delivered reports, leased and audited. families: a separate authentication realm with no path into staff surfaces. partner systems: a key with named grants, identity behind a grant of its own.
What the record is made of
Some of this is established school infrastructure; some is the work of connecting evidence to it. Keeping those two apart matters. A place to store an assessment is not yet a complete assessment history, and a lesson transcript is not yet a reliable account of which child demonstrated which skill.
Lesson evidenceLive Scheduled lessons captured, transcribed and searchable.
The registerLive Attendance, materials and a teacher’s note, marked by hand for every lesson.
Assessment recordsIn build Somewhere to hold what assessments have already said about a child.
Live rostersLive Who was in which group, resolved from dated memberships on every request.
The standards mapLive What a position is measured against: bina’s own connected standards graph.
The student cardLive The latest entries about one child, with a way back to their histories.
Roles and accessLive One record, and everybody sees exactly their part of it.
Student-created workIn buildAn assessment is more than its final mark.
Source and revision linksIn buildA route back from a useful summary to the material it rests on.
Collecting data is not the same as connecting it
A folder of lesson recordings, a reporting warehouse and a shared school record solve different problems. bina needs the last of these to work with the first two, not a claim that one storage technology can do every job. The test is what happens when a teacher asks a question the original export was not designed to answer.
| Question | Separate source tools | A reporting copy | The connected record being built |
|---|---|---|---|
| Where did this come from? | The source usually has its own local history. | An export may keep the value but lose its lesson context. | A source reference, date and lesson context travel with the evidence. |
| Which learner does it describe? | Each tool may use a different account or display name. | Identity has to be joined, and a bad match can spread. | School identifiers and dated memberships anchor the record; uncertain matches remain unresolved. |
| What happens after a correction? | The original changes; copies may not. | The next refresh can replace a value without explaining why. | The design keeps revisions linked and gives dependent views a way to follow them. |
| Who may read it? | Permissions belong to the source application. | A second access model is needed for the exported copy. | Purpose and role shape the view, including a separate grant for identifying information. |
| What does it cost to maintain? | Less integration work at first; more reconciliation between tools. | Useful for aggregate reporting, with extraction and freshness to manage. | More work on identity, provenance and lifecycle rules up front. Source-specific integrations still need ownership and maintenance. |
The commitments that shape it
A school record is valuable because somebody can rely on it later. That means keeping more than the latest answer: the source, the date, the responsibility and the boundary around its use. These are design commitments for the connected evidence layer, not an excuse to retain everything indefinitely.
The source survives the summary
A summary is an interpretation, not a replacement for the lesson passage or piece of work it describes. Keep the source reference and the version used to produce it, so a teacher can check the reasoning without reconstructing the lesson from memory.
A name is not an identity
A child can arrive under a nickname or a shared device account. A matching-looking label is not enough to attach evidence to a student record. The lesson roster provides context, but ambiguity needs to remain visible until it is resolved.
The role shapes the view
Teachers resolve to the children they teach; family-support staff and school operators need different registries. A partner counting children by level does not automatically need their names. Access belongs to a task as well as a person, including when that person uses an AI tool.
Correction has a route forward
A corrected source should not leave an old claim quietly circulating in three reports. Derived views need a traceable dependency and a clear response to replacement, withdrawal or removal. Version history and retention are related responsibilities, not competing promises.
Collection has a purpose
Learning support and safeguarding are different uses of lesson material. A shared technical foundation does not erase that distinction. Adding a new analysis needs its own access, retention and review decisions rather than inheriting permission simply because the recording exists.
The record is not the verdict
What was submitted, what a model inferred and what a teacher confirmed are different facts. Keeping them separate lets a later reader understand the decision instead of finding a machine suggestion presented as settled knowledge about a child.
What accumulates
A history ordinary teaching can write
Lessons, work samples, register entries and teacher observations already arise in the school day. Linking them as the work happens preserves context that would be hard to reconstruct a term later. The value is not the volume of recordings; it is the ability to ask a better question of the history.
New tools inherit a foundation
Each capability should not need its own roster, identity matching and import history. A common record gives reporting, school planning and the teacher copilot a place to begin, while letting each retain the permissions and interpretation its job requires.
Claims that can be checked
A useful account of learning connects an outcome to the teaching and evidence behind it. This foundation makes that investigation possible. It does not by itself establish what caused progress; that requires careful evaluation, not a larger dashboard.
Bring more student-created work and assessment history into the record without losing their source context. Resolve ambiguous identities before evidence is assigned, and make corrections visible to the views that depend on them. The teacher copilot builds on that foundation: it reads the evidence, proposes an interpretation and asks the teacher to judge it.