1. Who we are
As Written is operated by LaBarge Group LLC, a Michigan limited liability company, doing business as As Written (“As Written”, “we”, “us”).
Contact: support@aswritten.app
2. What this policy covers
This policy describes the As Written application — a Google Workspace web application that helps a teacher record, each school day, which of a student’s IEP or 504 accommodations were used.
For every category of data the application touches, it explains what we access, what it is used for, where it is stored and who owns that location, and who it is shared with.
This policy does not describe analytics or cookies on the aswritten.app website,
because the website uses none. If that ever changes, this policy will be updated before
the change is made.
3. The short version
Student records created with As Written are stored in the teacher’s own Google Drive, in a Google Sheet the teacher owns. We have no access to any file containing a student’s name.
What we hold is four small configuration settings per school district — none of which contains a student’s name — and a copy of that district’s own list of accommodation categories. We cannot see any student’s name, plan or daily record, and we cannot see a district’s dashboard either.
The rest of this policy is the detail behind that, including one section a teacher should read before using the application: §7, what your district can see about your use of it.
4. How the application runs, and why it matters
As Written is a Google Apps Script web application, configured to execute as the signed-in user. Every read and write it performs happens under the signed-in teacher’s own Google account and permissions, never under ours.
That single configuration choice is what keeps student data in the teacher’s own Drive:
- Spreadsheets the application creates are created inside the teacher’s own session, so the teacher owns them.
- Per-user storage the application uses is scoped by Google to that teacher and is not readable by any other teacher.
- The email address the application reads is the signed-in teacher’s own.
We chose this architecture. No platform limit forced it on us.
5. What the application accesses — scope by scope
As Written requests three permissions when a teacher first signs in. There are no restricted scopes.
About one line on Google’s permission screen
When you sign in, Google will tell you that As Written can “See, edit, create, and delete all your Google Sheets spreadsheets.”
That wording is Google’s, it applies to the permission rather than to this application, and we cannot change it. We would rather explain it here than have you meet it cold:
- The application only ever opens three kinds of spreadsheet: your own class spreadsheets, your district’s accommodation list, and your district’s status sheet.
- It has no way to browse, search or list your Drive. It does not request that permission, and the code contains no call that could.
- The narrower permission on the same screen — “only the specific Google Drive files you use with this app” — is the one we chose wherever Google gave us the choice. §5.2 explains why the broader one is unavoidable for the third kind of file.
5.1 Google Sheets
Accesses. Your own class spreadsheets, your district’s accommodation list, and your district’s status sheet.
Used for. Reading each student tab’s structure and accommodation list; writing one row per student per school day; creating and formatting a new student tab; maintaining two hidden bookkeeping tabs inside your own class spreadsheet; reading your district’s accommodation list; and writing one summary row per teacher per class to your district’s status sheet, where the district has asked us to enable that (§7).
Creates no storage on our side.
5.2 Per-file Google Drive access
Accesses. Only files the application itself created. This is Google’s narrow, per-file Drive permission — not full Drive access.
Used for — one operation, in one place. If any step of setting up a new school year fails after the new spreadsheet has been created, the application moves that spreadsheet to your trash so a half-built file is not left behind. That is the entire use of Drive access in the application.
Google’s broad Drive service appears nowhere in the application’s source code. It is prohibited by our own coding standards, because every one of its methods would require wider access than we ask for.
Why the Sheets permission in §5.1 cannot be narrower. This per-file permission reaches only files the application created or that you selected through a Google file picker. The application contains no file picker at all — a district points it at that district’s own accommodation list by pasting a link. Neither district file was created by the application, so this narrow permission cannot reach either one. The broader Sheets permission is what lets the application open a district-owned spreadsheet it has been pointed at, and nothing narrower does that.
Creates no storage on our side.
5.3 Your email address
Accesses. The signed-in teacher’s own email address, at three points:
- To show you your own address on screen — this is how someone realizes they are signed in to the wrong Chrome profile — and to identify your row in the district summary (§7).
- To determine the email domain only. The domain identifies your district and is how the application finds that district’s accommodation list. The address itself is discarded at this point. This is also the check that refuses personal webmail accounts.
- To stamp the submitting teacher’s address beside each row written into that teacher’s own class spreadsheet.
Stored. The full address is stored in your own spreadsheet, on every submitted row; and, where §7 applies, in your district’s status sheet. The domain alone is stored in four configuration keys in our Apps Script project (§6.3).
6. Where data is stored, and who owns each location
6.1 Student records — the teacher’s own Google Drive
Every student name, every accommodation listed on a student’s plan, the individual accommodation wording a teacher enters, every daily usage code and every lesson note is stored in a Google Sheet in the teacher’s own Google Drive, created inside the teacher’s own session. Student names are the spreadsheet’s tab names and also appear in each tab’s header block. The spreadsheet also contains two hidden bookkeeping tabs the application maintains.
Owner: the teacher. Not us, not the district. If a teacher stops using As Written, or if As Written ceases to exist, the spreadsheet and every record in it remain in that teacher’s Drive, readable without the application.
6.2 A temporary per-teacher cache
To avoid re-reading a class roster on every screen, the application keeps a copy of that teacher’s roster data — including student names, plan composition and accommodation wording — in Google’s per-user cache attached to our Apps Script project, under two keys per class. A third key holds only a date, a row count and a timestamp.
- Each key expires after six hours.
- Each is scoped by Google to that one teacher. No other teacher, and no district, can read it.
- The application uses no shared or cross-district cache of any kind.
This is the one place student data leaves the teacher’s Drive, and it is temporary. We state it plainly rather than calling it “temporary storage”, because a six-hour copy of a roster is a real thing and a district reviewer is entitled to know it exists.
6.3 What we store — four settings per district, and none holds a student name
Four settings are stored per district in our Apps Script project, each keyed by the district’s email domain and never by a student:
| What it holds | Contains a student name? |
|---|---|
| A copy of the district’s own accommodation list, used when the district’s file cannot be read | No. These are the district’s category labels, written by whoever maintains the district’s list. They describe kinds of accommodation, never an individual’s plan |
| A single counter (a number) | No |
| The Google Drive file identifier of the district’s accommodation list | No |
| Whether the district summary (§7) is switched on | No |
No setting the application stores can contain a student name, and no code path exists by which one could. We verified this by tracing every write the application is capable of making to this kind of storage — not by inspecting what happens to be there today.
6.4 Per-teacher settings
Three settings are kept in Google’s per-user storage attached to our Apps Script project, scoped by Google to each teacher: the teacher’s list of classes (a label, a color, and the Drive link to the class spreadsheet — a pointer, not the data), which class is currently selected, and the class-level default code for each accommodation category, keyed by category and never by student.
6.5 Your district’s own files
A district using As Written keeps two of its own Google Sheets:
- An accommodation list — the categories of accommodation in use in that district, plus a staff tab mapping teacher email addresses to building names. It contains no student data.
- A status sheet — the district summary described in §7. It contains no student data.
Both are created by the district, in the district’s own Google Drive, from templates we provide. The district owns them from the moment they are created. Nothing is transferred to us, and we are not given access to them.
6.6 Error logs
Uncaught errors in the application are forwarded to Google Cloud Logging in our Google Cloud project. Separately, three places in the application’s server code record the text of a handled error there.
What we have verified, and what we have not:
- No place in the application’s server code writes a student name or a student tab name to a log. The one place that records a failure to read a student tab records a tab number and a short code, deliberately, never a name.
- Two of those three log lines can carry something other than an error description. One is on a Google Drive operation, and Google embeds a file identifier inside Drive error text, so that line can record the identifier of a file the application created in the teacher’s Drive. One fires when a personal webmail account is refused, and records that account’s email domain.
- An uncaught error’s message and stack trace reach the same log. We have reviewed the places that can throw and found none that puts a student name into a message that escapes uncaught — but an unanticipated error is, by definition, unanticipated.
We deliberately do not tell you “nothing is logged”, because that would be false. What is true is narrower and checkable: no student name reaches our logs.
Retention: 30 days. Log entries are kept for 30 days in our Google Cloud project’s log storage, after which Google deletes them automatically.
7. What your district can see about your use of As Written
This section is for teachers. Please read it.
As Written can write a summary of each teacher’s documentation activity to a spreadsheet the teacher does not own and cannot see. It exists so a district can see documentation coverage across a building without anyone opening a file containing student names.
It is off by default. It is switched on only when a district asks us to enable it for their domain — it is not a setting a teacher or a district administrator can turn on themselves.
When it is on, here is exactly what is written
One row per teacher per class, at the end of every submission, with nine values:
| Column | What it is |
|---|---|
| Teacher email | Your email address |
| Building | Your building, from the district’s own staff list |
| Class or period | Your label for that class |
| Students on roster | How many active students are on that roster |
| Last documented date | The date of your most recent submission |
| Days this month | How many days you documented this month |
| Days logged | How many days you have documented in total |
| Last updated | When this row was last written |
| Class key | An internal identifier for the class |
So your district can see how many students are on your roster, when you last documented, how many days you documented this month, and how many in total. That is a record of your professional activity, and you should know it exists. We are not going to describe it as anything milder.
Three more things you should know about it
- No student data of any kind is written to this sheet, and that is enforced in code
rather than merely intended. Before the row is written, a check refuses the
entire row — never part of it — if there are not exactly nine values; if
any value other than your email address contains an
@; if the email column does not match the account actually signed in; if the three count columns are not whole numbers of zero or more; if the two date columns are not dates; if the class identifier is not in the expected form; or if any value is longer than 100 characters. A separate check compares your class label against every student tab in that class — including students who have been deactivated — and replaces the label with an internal identifier if it matches one, so that a class named after a student cannot put that student’s name into the sheet. - The write is silent, and it cannot make your submission fail. If it fails for any reason, the application records one short code and moves on. You are never told that the write happened, and you are never told that it failed. The application shows no indication of whether this feature is on for your district. If you want to know, ask your district, or ask us at support@aswritten.app.
- “Students on roster” counts active students only. If a teacher deactivates a student, the number goes down, and nothing on the dashboard explains why. Anyone reading that dashboard should know this before drawing a conclusion from a change in that number.
Who can see it
The district owns this spreadsheet and it is in the district’s own Google Drive. We are not given access to it. The application writes to it; we cannot read it.
No district has read access to any teacher’s class spreadsheet. The status sheet is the only thing a district sees from As Written, and it carries no student data.
One exception, stated because it is true during the pilot: a district taking part in our pilot may choose to send us coverage figures from that sheet, by agreement with them, so we can evaluate whether the product works. That is a hand-over the district decides on and controls — not access the application gives us. If your district does that, the figures involved are the ones in the table above.
8. What we can see
- No access to any file containing a student’s name. This is both a standing commitment and the architecture: class spreadsheets are created inside the teacher’s own session, and we are never added to them.
- No access to your district’s accommodation list or status sheet. The district creates and owns both (§6.5).
- What we do hold: the four domain-keyed settings in §6.3 — including a copy of the district’s own accommodation category list — and whatever reaches our error logs, which is the three lines described in §6.6 plus any uncaught error’s message and stack, kept for 30 days.
The honest one-sentence version: we can see which school districts use As Written and what categories of accommodation that district documents against — and we cannot see any student’s name, plan or daily record, any teacher’s class spreadsheet, or any district’s dashboard.
9. What the application does not do
Each of the following is the absence of a capability in the source code, not a policy promise we could quietly stop keeping. Each was verified by searching every source file and finding zero occurrences:
| The application has no… | Which means |
|---|---|
| Outbound network requests of any kind | No analytics, no telemetry, no third-party service, no error-reporting service. The application does not even request the permission that would allow an outbound request, so this is foreclosed at the configuration level as well as absent from the code |
| Email sending | The application never sends email, to anyone, for any reason |
| Broad Drive access | Only the per-file permission in §5.2 |
| Google Docs, Forms or Calendar access | No other Google service is touched |
| Shared or cross-district cache | Only the per-teacher, six-hour cache in §6.2 |
| Third-party request from the page itself | No web fonts, no content delivery network, no external stylesheet, no remote image. The application’s typeface is requested from your own computer; if you do not have it installed you see your system font |
No data about you or your students is sold, rented, or shared with an advertiser, a data broker, or any third party. There is no mechanism in the application by which data could reach one.
10. Retention and deletion
- Student records live in the teacher’s own Google Sheet and are retained and deleted by the teacher, under their own Google Workspace’s retention policy. We cannot delete them and cannot read them.
- The six-hour cache (§6.2) expires on its own.
- District settings (§6.3) persist until we delete them. None contains student data.
- Per-teacher settings (§6.4) persist until deleted; the roster copy is cleared whenever the application refreshes it.
- Your district’s files (§6.5) are the district’s to retain or delete.
- Error logs are kept for 30 days and then deleted automatically by Google.
One operating practice we ask every district to adopt: deactivate a student, never delete them. A documentation record that has been deleted cannot answer a question later, and we hold no copy to restore.
11. Your choices
- Revoking access. A teacher can remove As Written’s access to their Google account at any time at myaccount.google.com/permissions. The application stops working for that teacher. Their class spreadsheet and every record in it stay in their Drive.
- Deletion of what we hold. Write to support@aswritten.app. We will delete the district settings in §6.3. We cannot delete anything in your own or your district’s Drive — only you can.
- Asking what we hold about you. Write to support@aswritten.app.
12. Google API Services User Data Policy, including Limited Use
As Written’s use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically:
- We use Google user data only to provide and improve the features described in this policy.
- We do not transfer Google user data to any third party, except as required by law. The application has no mechanism to transfer it (§9).
- We do not use Google user data for advertising, and we do not sell it.
- We do not use Google user data to develop, improve or train generalized artificial-intelligence or machine-learning models.
- No human at As Written reads Google user data, except with the user’s explicit consent, where necessary for security, to comply with applicable law, or as part of an aggregated and anonymized operations summary. The architecture makes this stronger than a promise: we have no access to any file containing a student’s name.
13. Student records, FERPA, and our role
The records As Written helps a teacher create are education records describing a student’s IEP or 504 accommodations.
- The district is the educational agency that controls those records. As Written does not own them, does not hold them, and cannot read them.
- Where a district requires a vendor acting on its behalf to be designated a school official under FERPA’s school-official exception, or requires a separate data privacy agreement, we expect to enter into one on the district’s own terms. This privacy policy is not such an agreement and is not a substitute for one.
- We take no access to any file carrying a student name. It is a standing rule of ours, and it is why the architecture in §4 and §6.1 is built as it is.
14. Children
As Written is used by school staff. Students do not sign in to it, do not use it, and are never asked for anything by it. The application never contacts a student.
15. Changes to this policy
We will post any change on this page and update the date at the top. Material changes to how the application handles data will be notified to a district’s contact before they take effect.
Contact: support@aswritten.app