Procurement Packet

1. Product overview

StorylineIQ is a K-12 behavior, special-education support, and accommodation documentation platform used by educators and administrators inside a single district tenant.

• Educators document behavior, interventions, and accommodation delivery in the moment.
• Special-education staff turn plan content into daily classroom guidance and evidence.
• Administrators review school and district reporting, run privacy workflows, and control configuration.
• Students see only their own recognition experience; families receive educator-authored communication.

Controls: AC-02, AC-05

2. Student information we process

All district-entered data lives in 108 classified tables, of which 60 can contain student information. Every table records its educational purpose in a canonical inventory that CI enforces.

• Categories are published in reviewer language and generated from the canonical inventory.
• Each table records student-data and PII flags, allowed roles, source system, and authoritative system.
• A table added without a classification fails the build, so the inventory cannot drift from the schema.

Controls: PR-01

3. Educational purpose and district control

StorylineIQ processes student information only to deliver the service the district directs. The district decides configuration, retention, sharing, and departure.

• Districts configure retention windows, cross-class visibility, program designations, and MFA enforcement.
• Cross-class context is view-only: it is never exported and never included in family-facing packets.
• StorylineIQ does not sell student information, run behavioral advertising, or profile students for non-educational purposes.

Controls: AC-05, AC-07, RT-01, AI-04

4. Tenant isolation and access control

Isolation and authorization are enforced in the database by Row Level Security scoped to the caller's district, not by hiding interface elements.

• Roles are stored in a dedicated table; policies and server-side checks both enforce them.
• Teachers see their own students; special-education staff see their caseload; administrators are scoped to school or district.
• A repository policy audit and a tenant-isolation regression suite run as build gates.

Controls: AC-01, AC-02, AC-04, AC-06

5. Authentication and administrator verification

Accounts are provisioned by district administrators through invitation. Districts may require multi-factor authentication, and destructive privileged actions always require it.

• Password rules are enforced at signup, invitation acceptance, and password change.
• Per-district MFA enforcement is an administrator-controlled setting.
• Deletion execution and district offboarding require MFA plus typed confirmation regardless of that setting.

Controls: AC-03, AC-07

6. Encryption

Traffic is served over TLS with HTTPS enforced. Encryption at rest is a managed-platform control and is stated as an evidence gap rather than published as a capability.

• Transit encryption is verified by configuration StorylineIQ owns.
• Secrets are held server-side only and are excluded from exports and telemetry.

Stated limits

• At-rest encryption (DP-02) is owned by the hosting platform. Written confirmation has been requested and no at-rest encryption claim is published until it is on file.

Controls: DP-01, DP-03, DP-04

7. AI usage and boundaries

12 AI features are individually registered. All model access is server-side through a single approved gateway, and AI may summarize, recommend, explain, or draft — never decide.

• Student names are replaced with stable placeholders before prompts are built for narrative features.
• Discipline, eligibility, disability determination, grading, placement, and tier movement remain human decisions.
• AI-proposed changes cannot be written without explicit human confirmation.
• Direct client-side model access is blocked by a repository gate, so a bypass cannot ship.

Stated limits

• Two declared raw-content exceptions exist — Support document (IEP/ARD/FBA/BIP) extraction and Teacher list photo extraction (bulk provisioning) and Behavior capture sheet photo reading (draft rows only) and Accommodation support sheet photo reading (draft cells only) — where district-supplied documents or staff lists are transmitted as provided and require human review before use.
• Provider-side retention and training-exclusion terms are documented by the model provider, not by StorylineIQ (AI-04).

Controls: AI-01, AI-02, AI-03, AI-05

8. Audit and monitoring

Sensitive reads, exports, administrative changes, privacy request steps, and cross-class access are recorded with identifiers and outcomes rather than record content.

• Export and packet generation are audited actions attributable to a named user.
• Privacy request state transitions and offboarding stages produce their own evidence trail.
• Audit records are district-scoped and readable only by authorized administrators.

Stated limits

• Platform-side operational log retention (AU-02) is owned by the hosting platform and is not asserted as a StorylineIQ commitment.

Controls: AU-01, AU-03, AU-04, AU-05

9. Student data rights: review, copy, and correction

District administrators can search for a student and review, export, or hand over that student's complete StorylineIQ record without contacting support.

• Review is organized by category with provenance shown per record.
• Both a structured JSON bundle and a printable human-readable record are produced from the same coverage map.
• Fields owned by the district's source system are labelled so corrections happen in the authoritative system.

Controls: DR-01, AU-03

10. Controlled deletion

A district-initiated deletion request moves through a reviewed state machine and executes against a per-table deletion classification.

• Execution requires MFA plus typed confirmation by an authorized district administrator.
• Some records are anonymized rather than removed so aggregate history stays honest; each is classified deliberately.
• Removed students leave a source-identifier tombstone so a later roster sync cannot recreate the record.
• Requests retain categorical proof of the action while narrative fields are zeroed at terminal state.

Controls: DR-03, AC-03, AU-01

11. Retention

Retention is district-configured rather than vendor-imposed, and a scheduled purge acts on the configured window.

• Each table carries a declared retention class in the canonical inventory.
• Deletion behavior on student removal is declared per table, not inferred at runtime.

Stated limits

• Expiration of the managed platform's backups after application-level deletion is not yet evidenced in writing (BR-01).

Controls: RT-01, PR-01

12. District departure and offboarding

District departure is a 13-stage staged workflow: export first, read-only grace period, final approval, staged execution, then verification.

• A checksummed district archive must be issued and acknowledged before destructive execution is permitted.
• The tenant enters systemic read-only mode during the grace period.
• Execution is idempotent and resumable, and includes file-storage cleanup and integration teardown.
• Completion is refused while any table classified for deletion still holds tenant rows.

Controls: RT-02, AC-03, AU-05

13. Subprocessors

7 subprocessors and infrastructure providers support StorylineIQ. The published list is generated against a canonical register, and drift between them fails CI.

• Each entry states purpose, information categories, whether student information can reach it, and its privacy role.
• The register records the evidence behind each processing-location statement.

Controls: PR-02

14. Backup, recovery, and availability

Schema is migration-defined and the application tier is stateless, so recovery reduces to restoring the managed database and file storage. Managed backup specifics are unverified and are not claimed.

• Production data lives in a managed Postgres service; backups are performed by the platform, not by StorylineyIQ-authored jobs. StorylineIQ operates no self-managed backup process and stores no secondary copy of district data.
• The application layer is stateless and reproducible from source: builds are versioned and redeployable, so recovery of the application tier does not depend on restoring a server image.

Stated limits

• Backup cadence, retention, point-in-time recovery window, geographic redundancy, RPO, RTO, and uptime commitments are platform facts that are not yet evidenced in writing (BR-01, BR-03). No figure is published for any of them.
• The restore procedure is documented, but restore testing is not yet externally evidenced (BR-02), so no tested-recovery claim is made.

Controls: AC-01

15. Incident response and vulnerability reporting

A documented incident process and a published security contact exist. No contractual notification window is asserted.

• Security reports go to the published security contact and are triaged by the StorylineIQ team.
• Dependency review is part of release preparation.

Stated limits

• Incident response (IR-01) and dependency management (AS-02) are documented processes rather than test-verified controls, and no breach-notification guarantee is made outside a signed agreement.

Controls: IR-01, AS-01, AS-02

16. Agreements and contacts

A standard Data Processing Agreement is available, and privacy, security, and support contacts are published.

• Districts may execute the standard DPA or submit their own agreement for review.
• Privacy, security, and support each have a monitored address on the Trust Center contact page.
• State-specific evidence mapping is available alongside the control evidence matrix.

Controls: PR-02, IR-01