FRBOS Documentation

FRBOS is the internal operating system of FredericRepair IT Services: customers, repairs, service requests, quotes, technicians, inventory, organizations, internships, security and internal AI in one authenticated environment.

One root Owner / Administrator bootstraps the installation at /setup/administrator, then invites every other user. The Administrator controls who has access, which organization, which role and which modules. The Administrator never sees another person's password.

• • Root identity: enforced by a database invariant, not by the interface.
• • Sensitive actions are written to the audit log.

Managers run the daily operation: service desk, quotes, technician assignment, approvals, reporting and organization records, within the permissions the Administrator granted.

Repairs, service requests, evidence photos, parts, time logs, customer acceptance and remote-support participation. Technicians see the work assigned to them.

Call next, intake, queue folders, customer history and assignment from /support-queue/reception.

Interns, daily and weekly reviews, task and evidence approvals, evaluations and employment recommendations. Every supervisor relationship uses a real authenticated user UUID.

Orientation, assigned tasks, daily reports, evidence, skills and self-assessment. Training and supervised production are separated; interns never see unrestricted internal information.

The customer portal covers service requests, repair status, quotes and approvals, devices, technology health and remote-support consent. Customers can never create a staff account.

Authorization, endpoint agent, connection, granular permissions, troubleshooting and termination. Effective access is always grant ∩ endpoint capability ∩ live transport.

• • Signed production agent: NOT CONFIGURED
• • Rendezvous service: NOT DEPLOYED
• • TURN / relay: NOT DEPLOYED
• • Two-machine field acceptance: NOT COMPLETED
• • Status stays CONTROLLED PILOT / NOT FIELD PROVEN until all four are done.

Authentication and MFA through the authentication provider, role-based access, row-level security, audit logging, the Threat Centre and incident response. Private configuration, secrets and credentials are never published.

• • External threat-intelligence provider: NOT CONFIGURED
• • SMS / push security notifications: NOT CONFIGURED
• • In-app and email notifications: LIVE

Access tiers, knowledge approval, human approval before action and confidential-information handling for the FRBOS internal assistant.

The internal FRBOS organization is distinct from customer organization workspaces. Organization data is isolated by row-level security and never shared across tenants.

FRBOS has exactly one root Administrator. The single-root rule is enforced by a database invariant (a partial unique index on the owner role), not by the interface, so it cannot be bypassed from a browser. First-run setup at /setup/administrator creates that identity through the authentication provider and records the real authentication UUID. Every later account is created by the Administrator, either by invitation — the employee sets a password FRBOS never sees — or, where the business requires it, with a temporary credential handed over in person.

• • Temporary credentials are passed straight to the authentication provider; they are never stored, displayed after provisioning, emailed, logged or written to the audit trail.
• • An account opened with a temporary credential must replace it at first sign-in before any module is reachable.
• • Employees manage their own permanent password, recovery and MFA. The Administrator can never view them.
• • The Administrator assigns roles, module permissions, organizations and departments, and can suspend, revoke or reactivate accounts.
• • The Administrator cannot create a second active root Administrator, and the root account has no self-delete option.
• • Administrator recovery uses the authentication provider's secure recovery mechanism.
• • Role, permission and account-lifecycle changes are written to the audit log.

/command-centre aggregates what needs attention now: new security events, failed and suspicious authentication activity, permission violations, cross-organization access attempts, account changes, invitations, suspensions, support queue pressure, quotes awaiting approval and remote-support activity. It includes SECURITY EVENTS SINCE LAST REVIEW and a WHILE YOU WERE AWAY digest built only from stored events.

/team lists staff with status, role and presence. Administrators invite employees, provision temporary credentials where authorized, assign roles and module permissions, and suspend, archive, restore or revoke accounts. History is never deleted.

Customer records, devices and asset management, plus multi-tenant organization workspaces for businesses, schools, churches and agencies with departments, locations, shared assets and approval workflows. Tenant data is isolated by row-level security.

Intake, reception call handling, queue folders, triage, assignment and review from /support-queue. Requests carry their origin, customer history and the technician responsible.

The unified service workflow: request, queue, dispatch, assessment, quote, customer approval, repair, completion, invoice and customer history. Work in progress and invoicing are blocked by a database rule until the customer approves a sent quote.

The intended workflow is See → Authorize → Connect → Control → Troubleshoot → Document → Terminate. The customer requests assistance, the technician requests access, and the customer authorizes each capability separately: screen view, mouse, keyboard, clipboard, file transfer and application launch. Authorization is attended, time-limited and revocable at any moment by the customer. Effective access is always grant ∩ endpoint capability ∩ live transport, evaluated on the server.

• • Status: CONTROLLED PILOT / NOT FIELD PROVEN.
• • Browser screen sharing is view-only. It is not, and must not be described as, full operating-system control.
• • Operating-system control requires the native endpoint agent, and only for capabilities the endpoint actually reports and the customer has authorized.
• • Signed production agent: NOT CONFIGURED — REQUIRES EXTERNAL INTEGRATION (code-signing certificate).
• • Rendezvous service and TURN / relay: NOT CONFIGURED — REQUIRES EXTERNAL INTEGRATION (hosted infrastructure).
• • Two-machine, cross-ISP field acceptance: NOT COMPLETED.
• • FRBOS does not claim production-ready remote control until all of the above are complete.

/security/threat-centre records observable technical information about security-relevant events and lets an authorized reviewer classify, annotate and resolve them. Recorded evidence, where technically available, includes: timestamp; source IP; country; approximate location; region or city; ASN; network or provider; application or client; browser; operating system; user agent; target route, API or resource; event type; requested action; result; reason; authentication state; user UUID when legitimately known; organization when legitimately known; correlation or session information; and related events.

• • Evidence is presented in three clearly separated tiers: OBSERVED FACT, THREAT INTELLIGENCE and ANALYST INTERPRETATION.
• • External threat intelligence: NOT CONFIGURED — REQUIRES EXTERNAL INTEGRATION. Until connected, the THREAT INTELLIGENCE tier shows NOT CONFIGURED.
• • SMS / push security notification delivery: NOT CONFIGURED. In-app and email notifications: LIVE.

An IP address, country, ASN, ISP, browser or operating system does not by itself establish the identity of a person. These are network and client indicators only. FRBOS never invents a person's name, a person's photograph, a criminal identity or a threat-actor identity, and never builds a dossier on a private individual.

• • Where legitimate external threat intelligence provides an attribution, FRBOS shows the attribution together with its source, its confidence and its timestamp.
• • Where no such attribution exists, FRBOS shows: Identity: UNKNOWN.

/careers publishes openings; the hiring dashboard runs the pipeline from application through interview to selection. A selected candidate is converted to an employee through the Administrator invitation flow, which produces a real authentication identity. Advancement through Candidate → Intern → Trained Intern → Supervised Technician → Employee → Senior Technician → Supervisor is a management decision and is never automatic.

A standardized internship and supervision system covering applications, orientation, assignment, supervision, daily and weekly reports, tasks, evidence, skills, evaluations, final reports and employment recommendations, with reusable templates for IT support, infrastructure, networking, cybersecurity, repair, help desk, web and software, CCTV, business administration, marketing and AI positions. Training and supervised production are separated; supervisor access is relationship-scoped.

Quotes, invoices, payments, recurring revenue and membership subscriptions, with Canadian provincial tax presets (Ontario 13% HST by default) and CAD, USD and EUR currency support. Verified end-to-end billing is confirmed for Canada today.

FRBOS publishes an honest status for every capability rather than an aspirational one. A capability is LIVE only when it works end to end in FRBOS today.

• • Core operations (identity, customers, service requests, repairs, quotes, invoicing, organizations, internships, audit): LIVE.
• • Remote Support: CONTROLLED PILOT / NOT FIELD PROVEN.
• • Internal AI: CONTROLLED PILOT.
• • SMS and push notification delivery: NOT CONFIGURED — REQUIRES EXTERNAL INTEGRATION.
• • External threat intelligence: NOT CONFIGURED — REQUIRES EXTERNAL INTEGRATION.
• • Signed remote-support agent distribution, rendezvous and TURN/relay infrastructure: REQUIRES EXTERNAL INTEGRATION.

/admin/acceptance is the official Root Administrator acceptance-testing surface. It defines the A–S test framework: first-run root setup, root login, employee invitation, employee verification, password creation and change, MFA where configured, real UUID receipt, role assignment, permission assignment, authorized module access, unauthorized module blocked, password recovery, logout, second-device login, suspension, revoked access denied, second root creation denied, audit events verified and cross-organization access denied.

• • A recorded run must contain a real tester, date and time, device, browser, operating system, environment, evidence, result and, on failure, the exact error information.
• • A test with no recorded run remains NOT VERIFIED. FRBOS never generates evidence and never converts NOT VERIFIED into PASS.
• • At the time of this revision no acceptance run records exist, so all A–S tests are NOT VERIFIED.

FRBOS is designed around least privilege, server-side authorization, database-level row-level security, organization isolation, auditability, explicit customer authorization, credential protection, secure authentication, revocation, expiration and fail-closed controls. Authorization is never decided in the browser: role, permission and tenant checks are evaluated on the server and in the database, so modifying browser requests, local storage, React state, URL parameters or payload identifiers cannot grant access.

• • FRBOS maintains no password table. Passwords, reset tokens, MFA secrets and session secrets stay under the authentication provider's control.
• • Passwords and secrets never appear in audit logs, application logs, analytics, emails, browser responses or this document.
• • Remote access is attended, explicitly authorized, granular, time-limited, revocable and fully audited.
• • FRBOS does not provide, and will not provide, covert monitoring, credential collection or unauthorized remote access.

Capabilities that are intended but not implemented today are listed here so that no reader mistakes an intention for a feature.

• • Signed production remote-support agent with hosted rendezvous and relay: PLANNED — REQUIRES EXTERNAL INTEGRATION.
• • Managed (unattended) device access as a separate, explicitly contracted product: PLANNED.
• • SMS and push notification channels: PLANNED — REQUIRES EXTERNAL INTEGRATION.
• • External threat-intelligence enrichment: PLANNED — REQUIRES EXTERNAL INTEGRATION.
• • Spanish, Portuguese, Arabic and Swahili interface coverage: PLANNED.
• • Verified end-to-end billing outside Canada: PLANNED.