Primary use
Communications + story intelligence
Approved interviews, transcripts, sources, quotes, evidence, Story Leads, Story Concepts, rights, and institutional storytelling memory.
Lorescent / Trust Center
How Lorescent is built—and how institutional information is governed.
A technical and procurement-oriented view of Lorescent’s intended use, data flow, tenant model, access controls, AI processing, provider infrastructure, rights governance, and current security roadmap.
Procurement principle
Do not claim more than the current control can prove.
Lorescent distinguishes application controls, inherited infrastructure controls, institution-specific legal obligations, and future enterprise features. A provider certification is not relabeled as a Lorescent certification, and a planned control is not described as live.
At a glance
What the system is, where information moves, and what remains under institutional control.
Lorescent is intentionally narrower than a university ERP, SIS, CRM, clinical platform, or financial-aid system. Its risk model starts by keeping the data scope aligned to communications and storytelling work.
Source archive
Institution-controlled Google Drive
Original media can remain in institution-managed Drive folders while Lorescent stores transcripts, metadata, and derived story-intelligence records.
Application platform
Base44 production infrastructure
Lorescent is built and operated on Base44. Base44 states that its platform is SOC 2 Type II and ISO 27001 certified. Those are Base44 certifications—not an independent Lorescent SOC 2 claim.
AI processing
OpenAI API + Base44 model integrations
AI is used for transcription, bounded evidence extraction, synthesis, retrieval, and creative assistance. Human verification and editorial judgment remain required.
System architecture
From institution source to governed story intelligence.
This is the practical data path procurement and security teams should evaluate. Original media, Lorescent-derived records, model processing, and external integrations have different control boundaries.
01
Institution source boundary
An institution chooses the approved source locations. Google Drive mappings identify the folders Lorescent may work from; changing a mapping does not move, rename, or delete the institution’s underlying folder.
02
Server-side ingestion
Media and documents are processed through server-side workflows. For large private Drive media, Lorescent uses bounded range reads and direct transcription processing rather than exposing a reusable public media relay.
03
Institution-scoped data layer
Transcripts, Evidence Moments, People, Quotes, Sources, Story work, governance records, and other derived records carry canonical institution identity and are separated by tenant-aware access rules and server validation.
04
AI-assisted interpretation
Only the context needed for the requested analysis is assembled for model processing. Lorescent distinguishes source evidence from AI-assisted interpretation and does not treat generated output as verified institutional fact.
05
Human governance layer
Institution users verify evidence, approve story decisions, manage access, review sensitivity, maintain rights status, and decide what is appropriate for public communications or production.
06
Explicit outbound connections
Connected workplace tools use authorized connections and auditable actions. Integration logs are designed to store non-secret event metadata—not provider credentials or access tokens.
Current Lorescent controls
Application-level controls implemented in the product today.
These controls are part of Lorescent’s own architecture and workflows rather than future plan features.
Canonical tenant identity
Institution users are assigned an institution ID plus compatible institution name. Hardened server-side mutation paths fail closed when tenant context is missing or mismatched.
Role boundaries
Member, Institution Admin, Master Admin, and Storyteller are separate access levels. Storytellers use an assignment-scoped portal rather than the institutional intelligence application.
Administrative deprovisioning
Institution access can be disabled without erasing historical work. Master administration also supports forced re-authentication for active accounts.
Access and governance audit trails
Lorescent maintains access-change, integration, evidence-quality, and governance events so important administrative and review actions can be reconstructed.
Rights provenance
Release workflows retain document type, issuer, version, signature state, timestamps, references, archived PDF information, and integrity hashes where applicable.
Evidence provenance
Evidence Moments preserve source and passage context. Findings and story development can remain linked back to the source evidence that supports them.
Privacy-safe AI usage telemetry
AI usage records retain operational metadata such as model, provider, category, tokens, and cost without retaining the user’s prompt or search text in the usage ledger.
Source deletion boundaries
Removing an ingested Lorescent record does not automatically delete the institution’s original Drive source. Drive file deletion is separately permissioned and Drive folders are protected from deletion through Lorescent.
Data classification
Not every university record belongs in a storytelling platform.
Good security begins with data minimization. Lorescent’s default scope should stay with the information necessary to discover, govern, develop, and produce institutional stories.
Normal use
Communications and storytelling material
These are the core records Lorescent is designed to preserve, interpret, and develop into institutional storytelling memory.
Interview audio/video
Transcripts and quotes
Approved institutional source documents
Story concepts and editorial notes
Communications priorities
Rights and release status
Public-facing or institution-approved context
Review first
Student information that may be FERPA-regulated
Student interview material is not automatically outside FERPA. If the institution determines that education-record PII will be disclosed to or maintained in Lorescent, the agreement and workflow should establish the permitted purpose, direct institutional control, legitimate educational interest, access limits, redisclosure limits, and deletion/return requirements.
Student-specific nonpublic information
Interview content drawn from education records
Advising or academic-record details
Other student PII maintained as an institutional record
Do not store
High-risk regulated or secret data
Lorescent should not be used as the system of record for these categories. A university request to process them should trigger a separate security/legal review rather than ordinary onboarding.
Social Security or government ID numbers
Student financial-aid / GLBA customer information
Bank or payment-card data
Passwords, API keys, or authentication secrets
Clinical records or PHI
Psychotherapy/counseling records
HR disciplinary files
Immigration or identity-verification documents
AI is a processor and analytical layer—not the authority of record.
Lorescent uses AI because transcription and qualitative analysis are core to the product. Procurement should therefore evaluate exactly what is sent, to whom, for what purpose, under what retention terms, and how model output is governed.
Direct OpenAI API use
Lorescent currently uses OpenAI API services for selected model and transcription workflows. OpenAI states that API business inputs and outputs are not used to train its models by default. Standard API abuse-monitoring retention may apply unless an eligible retention control such as Zero Data Retention is approved.
Base44 model integrations
Some structured analysis workflows use Base44’s model integration layer. The exact provider path, retention behavior, and applicable subprocessor terms should be disclosed in the procurement packet for the production configuration.
No internet grounding for archive analysis
Lorescent’s core structured archive-analysis calls are configured without internet context so outside web material is not silently blended into institution-source analysis.
Evidence is not model truth
AI-generated summaries, patterns, Story Leads, and creative directions remain interpretations. Source evidence, quotations, rights, attribution, and consequential editorial decisions require human review.
Sensitive-attribute discipline
Flint and evidence-analysis instructions prohibit inferring sensitive identity attributes from names, photos, pronouns, majors, roles, or narrative context.
Infrastructure posture
Separate inherited platform assurance from Lorescent-specific assurance.
Lorescent benefits from Base44’s production infrastructure and OpenAI’s API controls. Procurement documents should identify those providers and their assurances without implying that Story Stroll has independently earned the same certifications.
SOC 2 Type II
Base44 states that its platform has completed SOC 2 Type II. Lorescent does not represent that inherited provider report as a separate Lorescent SOC 2 examination.
ISO 27001
Base44 states that its platform is ISO 27001 certified. Provider documentation can be supplied or requested during institutional review.
Encryption
Base44 states that platform data is protected with TLS 1.2+ in transit and AES-256 at rest. OpenAI likewise states that API business data is encrypted in transit and at rest.
Data location
Base44 stores app data in the United States by default. Base44 states that Elite and Enterprise workspaces can select other supported regions when residency requirements apply.
Identity roadmap
SSO is a deployment control with a defined upgrade path.
The product does not present a future enterprise feature as if it is enabled today. The Base44 tier should be upgraded when the institution’s identity and lifecycle requirements demand it.
Available now
Today · Lorescent application controls
Invite-based account provisioning, role-scoped access, institution assignment, account disabling, forced re-authentication, and server-enforced tenant boundaries are implemented in Lorescent.
Planned · Elite
Elite · App-level OIDC SSO
Base44 states that Elite and higher plans support app sign-in through OIDC identity providers such as Google Workspace, Microsoft / Entra ID, Okta, GitHub, and others. Lorescent plans to move to Elite before an institution requires SSO for production access.
Enterprise
Enterprise · Lifecycle + enforcement
Base44 Enterprise adds enforced organizational SSO across apps, SCIM provisioning, IP allowlisting, centralized audit-log and monitoring APIs, and additional enterprise governance controls. Lorescent would move to Enterprise when a client’s procurement profile requires those controls.
University legal + regulatory review
Which obligations matter depends on the data an institution actually puts into Lorescent.
Lorescent is not a compliance certification. The institution remains responsible for classifying its records and determining which legal basis and institutional policies apply; Story Stroll is responsible for meeting the contractual and security obligations it accepts as a vendor.
FERPA
Potentially applicable
If education-record PII is processed, the institution should determine the lawful disclosure basis and contract for direct control, permitted purpose, access limitation, redisclosure limits, and deletion/return. Lorescent should otherwise minimize the use of education-record data.
GLBA Safeguards Rule
Avoid regulated data
Title IV institutions have GLBA obligations for student financial-aid/customer information and must oversee service providers that receive it. Lorescent is not intended to receive financial-aid or other GLBA customer information during ordinary use.
ADA / WCAG
Procurement requirement
Public-entity digital services provided through contracts are subject to the Department of Justice Title II web/mobile accessibility rule. Lorescent should target WCAG 2.1 Level AA and document conformance through testing.
HIPAA
Out of normal scope
Lorescent is not positioned as a clinical or health-record platform. Protected health information should not be placed in Lorescent absent a separately approved architecture, BAA path, and institution-specific legal/security review.
PCI DSS
Keep out of scope
Payment-card numbers should not be stored in Lorescent. Commercial payment handling should use an appropriate payment processor and preserve separation from the story-intelligence system.
Procurement package
What a university security office should be able to ask Lorescent for.
These are the materials and contractual positions that turn product security into a reviewable vendor relationship.
HECVAT v4 / security questionnaire
Prepare for institutional review
Higher education security teams commonly use HECVAT or an equivalent vendor-risk questionnaire. Lorescent should maintain a versioned response packet grounded in actual architecture and provider documentation.
Data Processing Addendum
Contract requirement when applicable
The production agreement should define customer data, permitted processing, confidentiality, subprocessors, security obligations, incident notification, retention, deletion/return, and institutional audit/review rights. FERPA-specific terms should be included when education-record PII is in scope.
Incident response + notification
Formalize before broader rollout
Define the incident owner, escalation process, customer notice channel, provider escalation path, evidence preservation, recovery process, and contractual notification window. Institutions may impose shorter incident-reporting requirements on vendors handling regulated data.
Retention, export + termination
Define in the agreement
State what remains in institution Drive, what is stored as Lorescent-created data, the available export format, post-termination access period, deletion schedule, backup implications, and confirmation process.
Accessibility / VPAT or ACR
Formal assessment recommended
Public universities increasingly require WCAG 2.1 AA evidence and may request a VPAT/Accessibility Conformance Report. Lorescent should test core role workflows and publish an ACR rather than relying on visual inspection alone.
Subprocessor + change governance
Maintain as a living record
List infrastructure, AI, email, storage, and other subprocessors that can receive customer data; document the purpose and data category; and define how material subprocessor changes will be communicated.
Current transparency
Controls still being formalized as Lorescent moves from pilot to institutional production.
These are not hidden behind a “secure” badge. They are the next assurance layers expected as the client base grows.
01
Authenticated two-tenant runtime certification
The static/source tenant boundary is extensively tested, but the formal two-independent-client-principal runtime matrix should be completed as controlled institutional test accounts become available.
02
Independent Lorescent penetration test
Base44 performs platform security testing, but Lorescent should commission and retain an application-specific penetration test as institutional adoption grows.
03
Formal HECVAT v4 packet
Build and maintain a versioned HECVAT response with attachments rather than answering each university from scratch.
04
Accessibility conformance report
Run a structured WCAG 2.1 AA audit across public, Member, Institution Admin, and Storyteller experiences and produce a VPAT/ACR where procurement requires it.
05
Documented incident response + BCP/DR
Formalize incident response, recovery objectives, provider dependencies, backup/restoration assumptions, and customer communications in a controlled policy set.
06
SSO upgrade trigger
Move to Base44 Elite before SSO is contractually required; move to Enterprise when enforced SSO, SCIM, IP allowlisting, centralized audit APIs, or comparable enterprise controls are required.
Security review should happen before the data arrives.
Review the commercial and data terms, inspect Lorescent with fictional demo data, and define any SSO, retention, accessibility, FERPA, incident-response, or vendor-management requirements before production onboarding.