SectionBalance · Corporate IT
Technical & security review guide
Understand the product, assess the risks, and identify the evidence your organization needs before approval.
Documentation compared October 21, 2026 · Version 1.1.0 build 86 · Prelaunch · Production controls not independently verified
This guide does not certify compliance or grant approval. Confirm the deployed release and obtain the evidence listed below. Private team links, local device copies, exports, and authorized support analysis require particular review.
System overview
Manager iPhone / iPadLocal workspace and scheduler
↔HTTPS serviceCloud Run → Firestore / photo storage
↔Team browserPublished schedule and tasks via private link
Apple supports distribution and subscriptions. Optional email/support integrations connect from the backend. The public website and this guide are separate from the scheduling workspace.
1. Product and approval scope
SectionBalance, provided by Kithiva LLC, helps managers assign available staff to service areas, plan breaks and rotations, review fairness, publish schedules, and manage tasks. It supports current operations and is not the establishment's personnel, payroll, timekeeping, performance-management, hiring, termination, or regulatory system of record. Managers retain responsibility for reviewing schedules and meeting their organization's employment and record-retention policies.
| Area | Design, limitation, or evidence required |
|---|---|
| Users | Managers use the native iPhone and iPad app on iOS 17 or later. Team members use individual browser pages. |
| Processing | The scheduling engine runs on the manager's device. Online services handle account access, workspace synchronization, publication, tasks, and support. |
| Distribution | This guide applies to frozen SectionBalance 1.1.0 build 86 source. SectionBalance has not launched publicly. Documentation review does not establish App Store approval, external beta approval, or corporate security approval. The earlier build 79 internal TestFlight distribution remains historical evidence only. |
| Not intended for | Actual hours worked, clock-in/out, wages, tips, payroll or tax processing, benefits, medical or accommodation records, immigration information, discipline, termination reasons, performance reviews, hiring decisions, guest complaints, or automated employment decisions. Do not enter these data. |
| Record responsibility | Scheduled times are plans, not actual hours worked. The establishment must determine which records it must retain and save required exports in its approved record system. Kithiva does not represent that SectionBalance alone satisfies employment-record obligations. |
| Launch restriction | External beta testing may use fictional or tester-controlled data. Real-schedule pilot and production use require the approved employment-record launch gates, including minimum publication, archive handoff, bounded retention, purge, and removal of task-point influence from scheduling. |
| Review basis | Documentation compared on October 21, 2026 with frozen build 86 source at 7ba642775293205153fa7605602eb760228cb37e. The earlier October 9 review used b1f4541774dcb2a49933e08dd1ddd9a5c9c6f3cc, tagged sectionbalance-1.1.0-79; its execution evidence remains attributed to that review, not build 86. This is a source and release-evidence review, not a live production audit or independent security certification. The app source tag does not by itself identify the deployed backend revision. |
2. Architecture and data flows
The app is local-first: the editing workspace is saved on the device, synchronized online, and separately published as team-member views. A local save is not proof of an online save.
| Area | Design, limitation, or evidence required |
|---|---|
| Manager app | Swift / SwiftUI; local account-scoped files, recovery copies, and an on-device scheduling engine. |
| Application service | Node.js HTTP service on Google Cloud Run. Manager requests authenticate with an account session. |
| Persistent cloud data | Firestore for accounts, sessions, workspaces, published schedules, tasks, and support records. Cloud Storage holds task photographs when configured. |
| Team member pages | Server-rendered mobile web pages show the published schedule and eligible tasks; acknowledgement and task actions return to the service. Visible pages check for publication changes about every five seconds and on return to the page. |
| Public website and help | Separate website hosted through Cloudflare. The public help assistant calls an isolated Cloud Run service that retrieves only from a bundled, customer-neutral help corpus. It has no account, Firestore, Storage, schedule-backend, or operational-data client. Questions are not stored as conversation history. |
| Tasks and reporting | Tasks publish independently from schedules. Open, Claimed, and Completed track progress, with individual approval/rejection controls and establishment-time-zone due dates. Recurring occurrences are scoped to their week. Approved recognition points stay separate from scheduling opportunity. Roadmap PDF reports include selected-week overnight coverage but not tasks; publication archives contain PDF, JSON, CSV, and a checksum manifest. Reports and browser pages are not full workspace recovery copies. |
- The manager enters roster, availability, floors, sections, coverage plans, and rules; the app generates a draft on-device.
- Authenticated synchronization sends the workspace to the backend. Revision checks reject stale updates rather than silently replacing a newer online copy.
- Publishing sends member-specific schedule information. The app checks the accepted result; team pages show the published copy, not unsaved drafts.
- Task claims, completion submissions, and manager approvals are stored online. Any awarded points are associated with the approved task.
- Exports and support submissions create additional copies. Treat them under the organization's data-handling policy.
3. Information collected and where it goes
Use only the minimum information needed to operate the schedule. Employee schedules and private page links should be treated as confidential.
| Area | Design, limitation, or evidence required |
|---|---|
| Account and subscription | Manager name, email, account identifiers, password verifier, sessions, manager role and establishment access, invitations, and Apple subscription association. Apple handles payment details. Solo covers one establishment and one primary manager with zero delegates; Team adds up to three delegate managers. Approved US monthly prices are $129 and $169 respectively; Apple supplies checkout pricing and trial eligibility. Delegates and team-page viewers do not purchase a separate subscription for the establishment. |
| Workforce and configuration | Names, required email addresses, optional phone numbers, roles, working hours, days off, floor layouts, rules, assignments, and opportunity values. Stored locally and in synchronized workspaces. |
| Published activity | Member-specific schedules, acknowledgement state, task claims, completion, approval, and awarded points. Held by the backend and exposed only through the relevant access path. |
| Task photographs | Optional, manager-controlled completion evidence. Photos may include unintended personal information; train users to exclude faces, receipts, badges, and screens. |
| Diagnostics and support | Support messages and potentially sensitive schedule details. Review attachments before sending. Redaction and minimized issue summaries reduce exposure but should not be treated as proof that every attachment is anonymous. |
| Device exports | PDF reports, backups, and setup templates can create files outside the app. Current templates can include roster data; do not assume they are anonymous. |
| Assignment identity | Roster member IDs, not display names, identify assignment owners. Build 86 writes optional memberID ownership on assignments. Legacy name-only rows resolve only when the name identifies one roster member; ambiguous rows are preserved for review. A missing authoritative ID must not be reassigned to another person with the same name. Unresolved locked ownership can block generation until reviewed. |
| Setup template dates | A primary-manager setup import replaces configuration and clears operational workspace content after a safety checkpoint. When the imported time zone changes, build 86 preserves the selected civil year/month/day in the destination calendar rather than preserving an absolute instant that could move Monday into the previous week. Templates are not full workspace backups. |
4. Identity, access, and offboarding
There are three distinct access models. IT should explicitly approve each one.
| Area | Design, limitation, or evidence required |
|---|---|
| Manager authentication — implemented in source | Primary and delegate managers use individual email/password accounts. The service applies salted scrypt password hashing, server-side session records, establishment-role checks, and rate limiting on sensitive authentication operations. |
| Primary manager — implemented in source | The primary manager controls manager invitations and removal, establishment configuration, the permanent roster and normal weekly availability, floor and coverage plans, rules, opportunity settings, team-page links, setup templates, backup and restore, archive location, demo restoration, ownership transfer, and establishment deletion. Primary and delegate managers may both make audited, date-specific operational shift changes. |
| Delegate manager — implemented in source | A delegate may record absences and days off; add, shorten, extend, or remove a shift for one date; process schedule requests; generate and publish schedules; review findings; export schedule reports; and manage tasks. A delegate cannot alter permanent weekly roster hours. Protected establishment configuration and primary-only recovery, access, ownership, and deletion actions are denied by the service, not only hidden in the app. |
| Manager invitations — implemented in source | Invitations are bound to the invited email, expire after 48 hours, and pending invitations consume delegate capacity. An existing account authenticates in the invitation flow; a new delegate supplies first name, last name, and password without creating a separate establishment. Team allows up to three delegates; Solo allows none. Test acceptance with a new login, an existing login, an expired or replaced invitation, account-name editing, and concurrent manager use. |
| Device credentials — implemented in source | Session credentials use Apple Keychain with an AfterFirstUnlockThisDeviceOnly accessibility class. They are separate from workspace files. Review this class against the organization's locked-device policy. |
| Session lifetime — implemented in source | Sessions are created with a 30-day expiry. Validate actual revocation, password recovery, device loss, and account deletion with the release proposed for deployment. |
| Team pages — important limitation | The private URL is a bearer credential: anyone holding it can access the page and its permitted actions. It is not a corporate login, verified employee identity, or proof that the named person acknowledged a schedule. |
| Enterprise identity — not established by this review | SAML/OIDC single sign-on, manager MFA, SCIM provisioning, corporate directory groups, granular organization-wide roles, and centrally managed session policy must not be assumed available. |
| Offboarding — customer procedure | The primary manager should remove delegate access promptly, then verify that the former delegate can no longer open the establishment. Removal preserves the establishment's schedules, tasks, configuration, and audit history. Separately revoke team-page links when required, review remaining devices and exports, and arrange account/session removal with support as needed. |
| Subscription restoration | The SectionBalance manager account and Apple Media & Purchases account have separate identities. Verified receipts require server confirmation for the correct manager binding. Restore Purchases recovers entitlement, not workspace content. Retry confirmation retries a failed online acknowledgement without purchasing again. Missing or mismatched manager bindings require support; do not reset accounts or infer ownership from email similarity. Legacy products remain restore-only. |
5. Security controls and limitations
Implemented controls describe source behavior. Their effective operation depends on the deployed version and cloud configuration.
| Area | Design, limitation, or evidence required |
|---|---|
| Transport | Production application URLs use HTTPS. Corporate network validation should test certificate trust, TLS policy, and proxy behavior for the approved endpoints. |
| Cloud encryption | Google Cloud documents default encryption at rest. This does not establish customer-managed keys, dedicated infrastructure, or end-to-end encryption for SectionBalance. The application service must read operational data. |
| Local protection | Workspace files reside in the app sandbox; session tokens use Keychain. This review does not establish additional application-level encryption of workspace or exported files. Verify file protection, device backup exposure, and managed-device controls. |
| Private-page protections | Source applies no-store caching, no-index instructions, referrer restrictions, content security policy, frame protection, and checks on page mutations. These do not prevent a recipient from copying, forwarding, photographing, or printing content. |
| Account separation | Backend operations use manager/establishment scoping. Independent cross-account authorization tests and cloud IAM review are required evidence; shared hosting is not a dedicated customer tenant. |
| Secrets and operations | Engineering guidance specifies secure secret storage, least privilege, environment separation, and credential rotation. Obtain current deployment evidence rather than assuming every operational control is enabled. |
| Certifications and testing | No SectionBalance SOC 2, ISO 27001, independent penetration-test attestation, or regulatory certification is established by this guide. A cloud provider's certification does not certify this application. |
6. Devices, permissions, and connectivity
The released archive targets iPhone and iPad with iOS 17 or later. Validate the organization’s actual managed devices, OS versions, keyboard, VoiceOver, and browser configuration before operational approval.
| Area | Design, limitation, or evidence required |
|---|---|
| Network | Internet access is needed for sign-in/recovery, online saving, publishing, subscriptions, and team-page actions. No inbound connection into the customer's network is required by the described architecture. |
| Offline behavior | Local editing can retain pending changes when the account and workspace are available. Although scheduling computation is on-device, generation first synchronizes and reserves the shared week online, then validates the server revision before accepting a result. Do not promise offline generation, publication, task updates, or online recovery. A lost device with unsynchronized changes can mean lost work. |
| Production service | App and team pages use shifty-backend-362494783234.us-central1.run.app over HTTPS/443 in the checked source. Obtain a release-specific allowlist; do not broadly allow all run.app hosts. |
| Other connectivity | www.kithiva.com provides website/help. Apple services support distribution, purchases, and optional speech recognition. Service-to-service email and support integrations do not imply direct device access to every provider. |
| Optional input | Microphone and speech recognition support spoken rule entry with permission; rules can be typed instead. The implementation does not require on-device-only speech recognition, so do not dictate confidential information without approval. |
| Photos and exports | Photo selection/camera use for task evidence is optional according to task requirements. Files, sharing, and printing can move data outside the app; apply corporate controls and employee guidance. |
| MDM and DLP | Managed distribution, per-app VPN, managed open-in, remote wipe, conditional access, backup restrictions, and printing controls need customer-device testing. This guide does not claim an MDM-specific integration. |
| Native iPad and resizing | At regular width of at least 760 points, the five destinations use a scrollable sidebar; narrow windows use tabs. Navigation stacks and sheet drafts remain mounted across resizing. All iPad orientations are supported; iPhone remains portrait. Command-1 through Command-5 select destinations; supported Cancel/Close actions respond to Escape. The app retains one shared store and foreground polling task; multiple-window support is not enabled. System forms use light appearance. |
| Language and accessibility | English and Spanish primary navigation and immediate forms, localized weekdays, full VoiceOver date labels, selected-day traits, and large-text scrolling are implemented. User-entered labels and stable scheduling identifiers are not translated; team-page language is separate. Acceptance recorded the Settings heading remaining English immediately after a language switch. Do not represent every control as translated or automated tests as full physical-device accessibility certification. |
7. Hosting, providers, and residency
The checked application configuration points to a Cloud Run service in us-central1. That is not proof that every database, backup, log, support service, or provider processes data only in that region.
| Area | Design, limitation, or evidence required |
|---|---|
| Google Cloud | Application hosting, Firestore storage, task evidence storage, infrastructure operations, and the separately deployed public help assistant. The help assistant uses its own service identity with Vertex AI access and no operational-data role. Request current resource regions, IAM, logging, backup, and deletion configuration. |
| Vertex AI — public help only | The public help assistant sends the user's question and a small set of retrieved public-guide excerpts to a Google-hosted Gemini model. It is instructed to answer only from those excerpts and refuse customer-specific requests. Users are warned not to enter personal data, credentials, invitation codes, private links, or schedule details. |
| Apple | App distribution, subscription validation, purchase records, and optional speech services. Apple controls its own account and transaction processing. |
| Resend — conditional integration | Recovery/support email when configured. Confirm enabled use, message contents, retention, and contractual terms. |
| GitHub support integration | The support workflow can create a minimized engineering issue and reconcile its closed status back to the in-app ticket. Full diagnostic attachments and private team links should not be copied into GitHub. Request field mapping, repository access, audit, retention, and redaction evidence. |
| Cloudflare | Public Kithiva website/help hosting, with normal web request processing. Confirm website logging and privacy terms separately from scheduling storage. |
| Contractual review | Request the current provider/subprocessor inventory, processing locations, data-processing terms, cross-border arrangements, and change-notification process. No customer-selectable residency or dedicated hosting is promised here. |
8. Retention, deletion, and exit
SectionBalance uses bounded operational retention so it does not become an employment-record archive. These periods support delivery, recovery, security, and support; they are not a substitute for the organization's legally required record-retention program. Request production evidence for the daily retention sweep, customer archive handoff, account deletion, cloud backup behavior, and provider copies before approval.
| Area | Design, limitation, or evidence required |
|---|---|
| Synchronized generated weeks — implemented limit | All current and future schedules plus the newest eight completed weekly snapshots. Older completed snapshots are removed from the synchronized workspace. |
| Device recovery backups — implemented limit | 30 days, capped at 60 backups or 100 MB while preserving the newest backup. Selected-folder copies remain under customer control. |
| Published personal pages — implemented limit | Available through the scheduled week and for 60 days afterward, with earlier primary-manager revocation. The daily retention process removes expired weeks and empty portals. |
| Completion photos — implemented workflow / policy | Purge after approval or rejection, and deletion with the related task/account where applicable. Request evidence of failure retries and removal from storage. |
| Completed task detail and audit history — implemented limits | Completed task detail: 90 days after approval; the separate awarded-point ledger remains while the account is active. Manager and delegate audit events: 365 days. |
| Publication archive evidence — implemented limit | Status, destination description, timestamp, and checksum are retained for 90 days. Archive contents remain in the customer-selected location and are not uploaded to Kithiva. |
| Support — documented policy | Diagnostic snapshots: 90 days. Closed support conversations: 365 days after last update. Confirm automated enforcement. |
| Logs and cloud backups — confirmation required | Actual retention, backup/PITR configuration, access, and delayed deletion must be supplied for the deployed environment. |
| Account deletion and exit | Account deletion removes the account, sessions, synchronized workspace, published links, tasks, evidence, and associated support diagnostics except records legally required for security, fraud prevention, disputes, or agreement enforcement. Apple subscription cancellation and customer-controlled files are separate. |
| Customer-controlled copies | Export needed records before closure. Reports, downloaded files, shared links, printouts, and external device backups require a separate customer cleanup process. |
9. Reliability, change control, and support
Local safety copies, revision-aware synchronization, publication verification, and audit/diagnostic records support recovery. They are not a substitute for a tested service continuity plan.
| Area | Design, limitation, or evidence required |
|---|---|
| Recovery | Request a recent cloud restore test and device-to-online conflict recovery test, with measured recovery time and recoverable data age (RTO/RPO). No uptime SLA or recovery guarantee is established here. |
| Availability | Cloud Run supports service scaling; actual limits, capacity, alerts, on-call response, and failure behavior need release-specific evidence. Agree a manual scheduling fallback. |
| Audit | The app records shared operational changes with the acting manager's display name or email, including delegate actions. Review generation, publishing, assignment edits, date-specific shift additions or changes, absences, requests, tasks, and other permitted delegate changes during the pilot. Do not assume tamper-evident retention, every-read access auditing, SIEM export, or organization-wide audit administration. |
| Release management | Development, staging, and production configurations are separated in the design. For approval, request the app build, source commit, production Cloud Run revision, environment verification, dependency/vulnerability scan results, regression results, rollback checkpoint, and known-defect record. |
| Incident handling | Engineering policy covers containment, evidence review, customer impact, and notification assessment. Agree named contacts, escalation, contractual notification times, and incident exercises; this guide is not a notification SLA. |
| Support access | Use support@kithiva.com to coordinate review. Do not send credentials or private team links in ordinary tickets. Agree a secure channel for evidence and any necessary customer-data access. |
| Fairness support dashboard | A separate read-only support tool can analyze generated schedule history, team-member names, assignment exposure, starting-assignment changes, and opportunity trends. Access uses a support credential and is recorded in a support audit log. Approve who may use it with production data, and request evidence for credential storage, rotation, revocation, access logs, retention, and customer authorization. |
| Local/cloud reconciliation | Account-scoped local storage and canonical authenticated account/workspace identity keep workspaces separated. Revision-aware synchronization rejects concurrent edits instead of silently overwriting them. Unchanged loads do not dirty the workspace or advance revisions. Transient save failures retry a bounded number of times; Data status offers Try Again. A failed save is not a reason to reload and discard pending local edits. Delegates cannot substitute a local recovery copy for the shared server workspace. |
| Backup restoration | Primary-only restoration creates a safety checkpoint and replaces content while retaining the live client’s expected cloud revision and last-sync baseline. It preserves an existing conflict and records the current acting manager durably. It does not adopt a newer server revision to bypass a conflict, republish schedules, or restore Apple purchases. If local persistence fails, the app reports failure; verify local durability and online save status before proceeding. |
| Generation and publication | Roster edits mark drafts for explicit regeneration and preserve existing assignments/history. Generation uses a shared-week lease, a safety checkpoint, current input checks, and a final server-revision check. Cancel, week changes, roster edits, and backgrounding discard unfinished work while retaining the previous schedule. At 60/90/120 seconds the app provides progressively more feedback and then cancel/diagnostic actions, not an automatic timeout. A generated draft must still be reviewed, saved online, and published before team pages change. |
| Coordinated upgrade and rollback | For the shared-workspace pilot, update every manager and delegate device together before edits resume. Build 77 must not edit the upgraded workspace: its assignment codec discards unknown owner IDs when re-encoding. Preserve a full versioned checkpoint; PDF/CSV reports are not lossless identity backups. This coordination is an operational requirement, not server enforcement. Downgrade or restoration requires a separate reviewed plan covering lost subsequent edits; use a separately reviewed higher build for a distributed fix. |
| Release evidence and limits | Historical build 79 review evidence: its final source CI passed on both iPhone and iPad: 509 tests per family, zero failures, four optional skips each, plus security checks. Staging acceptance verified the cross-time-zone civil-week import and backup restoration with online saving. Physical TestFlight 78 supplied subscription restore and relaunch evidence for the byte-identical subscription subsystem in 79; this is not a claim that build 79 itself was physically installed for that test. These historical results are not a fresh build 86 test run. The October 21 documentation comparison did not execute app acceptance tests or independently verify deployed production controls. Internal distribution does not establish a public App Store release or certify all production controls. |
10. Privacy and employment governance
The establishment normally determines the business use of employee information. Confirm controller/processor responsibilities in the customer agreement rather than relying on this guide as legal advice.
| Area | Design, limitation, or evidence required |
|---|---|
| Employee notice | Explain roster collection, publishing through private links, task photographs, points, and retention. Decide whether personal-device use is permitted. |
| Data minimization | Use unavailable dates without medical explanations. Do not enter protected traits, guest information, or financial account data. |
| Scheduling decisions | The scheduler uses configured operational rules, availability, section opportunity, and schedule history. Task recognition points and data from connected products are not scheduling inputs. Scores are not guaranteed earnings or an employee performance rating. Managers must review fairness and operational exceptions. |
| Human review | Do not use generated findings or points as the sole basis for adverse employment decisions. Validate break rules and local employment obligations with the appropriate internal specialists. |
| Requests | Agree procedures for employee access, correction, export, deletion, and manager authorization. Link revocation is an access action, not proof of full data deletion. |
11. Corporate approval checklist
Record an owner, evidence reference, decision, and review date for each item. Treat any unmet mandatory control as an approval blocker or a formally accepted exception.
- Business owner: identify establishments, users, approved release, data categories, and permitted use.
- Security: decide whether bearer-link team pages and current manager authentication meet policy. Do not substitute device controls for missing required application identity features.
- IT operations: test installation, network access, optional permissions, device loss, backups, exports, printing, and offboarding on managed devices.
- Privacy/procurement: approve the privacy policy, provider list, processing locations, contract, deletion terms, employee notice, and incident contacts.
- Vendor assurance: obtain current security testing, vulnerability remediation, access-control evidence, retention/deletion results, cloud recovery tests, and release/change records.
- Pilot owner: use fictional data first; test cross-account isolation, revoked links, denied permissions, stale/offline saves, publication verification, and task approval with and without photos.
- Access pilot: invite delegates with new and existing logins; verify the three-delegate limit, concurrent changes and publishing, date-specific shift changes, primary-only permanent roster and recovery controls, audit attribution by delegate name, immediate revocation, and preserved establishment data after removal.
- Operational evaluation: generate several weeks, review each Roadmap before publishing, compare against normal manager decisions, measure avoidable corrections and management time, then publish only to a controlled test group.
- Approver: document approved scope and exceptions. Set a re-review date and triggers for new providers, data types, authentication changes, or major releases.
References and evidence
The October 21 documentation comparison used frozen build 86 source at 7ba642775293205153fa7605602eb760228cb37e and retained engineering and acceptance evidence. The earlier review used b1f4541774dcb2a49933e08dd1ddd9a5c9c6f3cc (sectionbalance-1.1.0-79); historical test counts and physical-device observations retain their original build attribution. No new build 86 runtime, deployment, or certification result is claimed here. Source review does not confirm that every control is active in production. Internal runbooks, resource inventories, and test evidence should be exchanged securely, not posted on this public guide.
- Kithiva privacy policy — review alongside the agreed customer terms.
- Apple TestFlight — beta distribution and tester feedback overview.
- Apple TestFlight process — build duration, invitations, updates, and feedback.
- Google Cloud: default encryption at rest — provider capability, not an application certification.
- Apple: Keychain data protection — platform protection and accessibility classes.
Request the release-specific review pack or submit your organization's questionnaire to support@kithiva.com. Kithiva should confirm which materials are available and identify remaining gaps.
Return to the SectionBalance user guide →