Understand incoming work
Surface important requests, unresolved topics, and follow-ups from sources a user has permission to access.
Public edition · Updated October 23, 2026
NOVA Platform Overview
A central workspace for authorized AI assistance, connected information, operational visibility, and controlled business automation.
NOVA is evolving from an interactive presentation into a secure operational application. Its direction is to help people review requests, understand source information, prepare follow-ups, and coordinate work through one interface. Identity and private email foundations are implemented; reporting and scheduled workflows will be added incrementally.
Release position. The latest reliability improvements are implemented and tested locally. Deployment of those application changes and live provider acceptance checks remain pending. This published overview is a separate document deployment.
01Product purpose and intended outcomes
Business information often lives across inboxes, customer systems, transaction records, workforce tools, and spreadsheets. NOVA is intended to provide a consistent place to find authorized information and turn it into clear next actions, while preserving the source systems as the systems of record.
Reduce repeated preparation
Help assemble email answers, draft responses, and eventually recurring reports with explicit reporting periods and source references.
Coordinate responsibility
Develop shared tasks, approvals, and completion tracking so a proposed action has a clear owner and review path.
Make automation observable
Show whether a connection is saved, data has been retrieved, and a workflow has actually run. Each state should have its own evidence.
These are product objectives. A reduction in missed requests, preparation time, or reporting effort has not yet been measured.
02Application experience
The public demonstration lets visitors explore sample agents, role previews, and simulated workflows. The authenticated workspace is a separate experience backed by real account approval and access rules. Demo role switching is a presentation feature; it does not assign permissions to real accounts.
1. Sign inUse an eligible account. New users receive Pending access until approved.
2. Connect privatelyAn approved user authorizes their matching Google mailbox with read-only access.
3. Review and askPreview messages, ask email questions, and review display-only response drafts.
The broader workflow catalog remains visible as a product roadmap. Those workflows stay off until their integrations, permissions, processing, and acceptance checks are implemented.
03System architecture
The current implementation keeps the existing web application, with server routes responsible for protected integration work and the database responsible for persistent access policy. Public presentation data is separated from private staff activity.
| Layer | Current responsibility | Expansion direction |
|---|---|---|
| Browser interface | Public demo, staff dashboard, role-aware navigation, connection controls, assistant chat, and optional voice dictation. | Source-aware reporting, useful empty states, and permission-appropriate task and approval screens. |
| Identity and database | Supabase authentication, profiles, Pending approval, database access policies, role audit, and private integration storage. | Explicit permissions for reports, viewers, retention, and shared work records. |
| Protected server routes | Cloudflare Pages Functions validate users and active profiles, handle Gmail OAuth, manage encrypted credentials, and call approved services. | Connector-specific access checks and consistent status/error handling. |
| Private Gmail connector | Google OAuth with read-only access, matching mailbox checks, inbox retrieval, token refresh, and disconnect. | Live lifecycle acceptance and, separately, evidence-linked summary processing. |
| AI request processing | OpenAI-backed assistant code receives the user request and selected messages from that user's authorized connection. | Stronger answer evaluation, structured source references, and usage controls as adoption grows. |
| Scheduled execution | Durable summary jobs, automatic schedules, and full background monitoring are not implemented. | Job/run records, bounded retries, duplicate prevention, timezone handling, and failure visibility. |
A future summary pipeline would follow: authorized source → bounded retrieval → processing → private saved result → authorized dashboard delivery. Scheduling and durable delivery are future work; connecting Gmail alone does not create this pipeline.
04Identity, roles and data boundaries
The current account policy permits an approved organizational email domain. A designated primary administrator controls role assignment. New accounts start as Pending, and users cannot assign themselves privileged roles.
| Role | Current interpretation | Reporting direction |
|---|---|---|
| Pending | Account created; operational workspace access remains restricted. | No operational data until approval. |
| Owner / Admin | Broader workspace navigation; account management is restricted to the designated primary administrator by current policy. | Explicitly approved operational views, with source-specific authorization. |
| Minority Shareholder | Restricted navigation and approved-user features. | Approved aggregate reporting; future reports require server-enforced scope. |
| Team Member | Team-oriented navigation and an individually authorized Gmail connection. | Assigned work and permitted operational information. |
Role visibility does not grant access to another person's connected inbox. Each Gmail connection belongs to its authorizing application user. Shared or delegated inbox access is not automatically inherited and is not implemented by the current matching-mailbox flow.
Provider credentials stay on the server and encrypted integration tokens stay in protected storage. Staff chat, drafts, and previews are kept in page memory and cleared on account/access changes. Selected email content is sent to the configured AI provider when an email question is processed; this requires an approved processing purpose.
05Capability inventory
| Capability | Current state | Boundary or dependency |
|---|---|---|
| Public presentation | Implemented | Sample records, simulated runs, and role previews. |
| Account approval | Implemented; first administrator login verified earlier | New users start Pending; local policy tests cover restrictions. |
| Private Gmail | Implemented in source; latest hardening locally tested | Matching mailbox, active profile, and read-only authorization required. Live revalidation pending. |
| Email Q&A | API and interface implemented | Uses the signed-in user's connection and a bounded set of selected messages. Answers still require user review. |
| Draft preparation | Display/copy only | No email sending or saving drafts to Gmail. |
| Voice input | Conditional browser capability | Requires compatible browser support and microphone permission. |
| Daily email summary | Planned | Needs schedules, durable runs, retention, authorized viewers, and monitoring. |
| Customer-management reports | Planned | Read-only scope, approved fields, and source reconciliation required. |
| Transaction / workforce reporting | Planned | Supported APIs or approved exports and agreed metric definitions needed. |
| Shared tasks and approvals | Staff automation inactive | Persistent records, access rules, action owners, and review flow needed. |
| Continuous autonomous operations | Not established | Requires reliable job execution, monitoring, and operation-specific approval. |
06Recent reliability and privacy improvements
| Area | Implemented improvement |
|---|---|
| Gmail identity | The confirmed application identity, active user profile, and verified Google mailbox must match. Existing mismatched connections are refused. |
| OAuth and tokens | Read-only grants are checked; authorization state expires and is single use. Refresh-token reuse is restricted to the same mailbox. Missing offline access requires reconnection. |
| Disconnect | Locally stored credentials are removed and Google revocation is attempted. A failed provider revocation is reported separately. |
| Request reliability | External requests have a 15-second deadline. Account changes cancel pending browser requests and reject late results from the previous account. |
| Accurate status | Gmail connection, AI configuration, and workflow activity are shown separately. A saved connection does not establish provider reachability; a configured AI key does not prove a successful model request. |
| Private state | Chat, drafts, inbox previews, and voice capture are cleared on account/access changes. Staff content is not persisted in localStorage. Routine same-account refresh preserves the current chat. |
Three states remain distinct: connection saved, provider request successful, and automation executed. Configuration availability is not a provider-health test. The interface should not imply otherwise.
07Creation minutes and key decisions
These are reconstructed development decisions from the project conversation, not a verbatim meeting transcript. Exact session durations and person-hours were not recorded.
| Period | Work and decision |
|---|---|
| October 20–21, 2026 | Created the presentation dashboard with animated assistant, automation concepts, role previews, and sample interactions. Retain the public demonstration independently. |
| October 21 setup | Added organization-domain account policy, Pending access, profile roles, role audit, and administrator approval. New users cannot grant themselves privileged roles. |
| October 21 setup | Established a separate application hosting environment while preserving the original demo. Configured Google sign-in and verified the first administrator login. |
| October 21–23 | Developed per-user read-only Gmail authorization, encrypted credential storage, inbox preview, assistant answers, and display-only drafts. Scheduled summaries remained pending. |
| October 23 review | Reviewed architecture with the requested installed development specialists. Agreed to extend the existing app and use only relevant specialists per task to reduce unnecessary context and token use. |
| October 23 reliability work | Selected reliability as the target. Hardened mailbox identity and token handling, separated service status from automation activity, protected account transitions, and expanded automated tests. |
Development-agent policy: installed specialists assist with building the platform. They are not background automation agents already operating inside the product. Small changes use the primary development agent; scoped specialists are used when the work benefits from them.
08Implementation roadmap and acceptance criteria
| Stage | Delivery | Acceptance condition |
|---|---|---|
| 1. Verify the current pilot | Deploy the locally tested reliability changes after authorization; exercise live sign-in, consent, reconnection, and assistant requests. | Two approved users remain isolated; Pending access is denied; revoked access and provider errors are accurately reported. |
| 2. Private daily summary | Agree on mailbox, topics, schedule, timezone, viewers, retention, and dashboard delivery. Implement durable jobs and run history. | Runs can be traced to authorized source messages; duplicates and failures are visible; users can review and stop processing. |
| 3. One read-only report | Connect a single approved customer-management dataset and define one operational report. | Totals reconcile with the source for an agreed period; restricted records never reach unauthorized browsers. |
| 4. Extend reporting sources | Add transaction, workforce, and specialist datasets using supported APIs or approved exports. | Each metric has a definition, source, reporting period, refresh timestamp, and visible partial/error state. |
| 5. Controlled work execution | Add persistent tasks and approvals, followed by individually authorized actions. | Action ownership, approval, audit, retry behavior, and recovery are defined before source-system writes are enabled. |
Before each integration, confirm its owner, supported access, permitted fields, viewers, refresh frequency, and cost expectations. Retention and excluded content must be defined before expanding stored operational data.
09Validation, release status and version
Application version: 1.0.0. The version metadata has not been changed by the recent reliability work. The project remains an authenticated working pilot, with the latest improvements awaiting application deployment and live acceptance.
Local validation on October 23, 2026: all 17 automated tests passed. The frontend build and Cloudflare Pages Functions compilation passed. Coverage includes database domain/role/isolation rules, public-demo preservation, staff empty states, mocked Gmail and assistant flows, OAuth rejection paths, token handling, disconnect outcomes, and stale-response protection.
Backend integration tests use fake provider responses and credentials. They do not establish live provider health, scheduled execution reliability, or production readiness. Remaining checks include two-account live isolation, revoked access, reconnect behavior, and an actual assistant request after deployment.
The public demonstration and application remain independent. Publishing this overview changes the document site only. Future application releases should record the deployed version, completed acceptance checks, and remaining limitations.
10Operational success measures
Once live acceptance is complete, measure outcomes against a baseline: summary completion rate, missed or duplicate runs, source reconciliation accuracy, follow-up completion, and time spent preparing routine answers or reports. Monitor provider usage and cost alongside usefulness. No savings or performance result is claimed before those measurements exist.
Public edition: company identity, account addresses, application URLs, credentials, private messages, and operational records are excluded. Creation minutes are reconstructed from the development conversation and project records; exact work durations were not recorded.