Log in Get started

OhioMade Platform Laws

These laws define how OhioMade handles identity, business relationships, realm access, onboarding, workforce operations, payroll execution, shared infrastructure, audit history, and mobile-first platform consistency.

This page is the architectural doctrine for the OhioMade ecosystem. Apps may extend OhioMade, but they may not bypass Identity, PaperTrail, Workforce, Payroll, explicit access scopes, or audit ownership.

Core Identity Laws

Identity Sovereignty

Businesses do not own users. Businesses authorize relationships. OhioMade owns the identity layer. A human identity survives job changes, business changes, email changes, and revoked company access.

Permanent User ID

Email does not own the account. The permanent user ID owns the account. Personal emails, usernames, and business aliases may resolve to one identity without fragmenting history.

Relationship Law

Memberships are relationships, not ownership. A business may grant, limit, suspend, or revoke access without deleting the person’s permanent OhioMade identity.

Revocable Alias Law

Business email aliases are revocable tools. Losing a business alias must not destroy the person’s identity, history, audit records, or person-owned services.

Person-Owned Services

Some services may belong directly to the person instead of a business. Identity must support both person-owned and business-owned access without confusing the two.

No Hidden Ownership

Apps must not hide ownership assumptions in local tables. Identity, business membership, realm access, and scope rules must remain visible, consistent, and traceable.

Access & Authority Laws

Realm vs Authority

Realm access only means app entry. It does not automatically grant power. Role, scope, business context, and explicit helper checks determine what the user can actually do.

Explicit Access

No permission guessing. No reflection-based authority routing. No generic access bridges. No helper auto-discovery. Authority must be explicit, traceable, and reviewable.

Business Context

Every business-aware action must resolve the active business context. A user may belong to multiple businesses, but every operational action must be tied to one clear business lane.

Least Power

Access should grant the smallest practical authority needed for the task. Owner, manager, employee, contractor, vendor, and agent lanes must not blur.

No Silent Elevation

A successful login, realm assignment, or business membership should never silently become admin authority. Elevation must be explicit and auditable.

Session Scope

Login proves identity. Session context must still respect realm access, business membership, scope checks, MFA state, trusted device state, and operational limits.

Onboarding & Pipeline Laws

Invite → Join → Approve

Invite, join, and approve are separate states. An invite creates a controlled lane. A join submits a request. Approval creates the authorized relationship and downstream access.

PaperTrail Owns Documents

PaperTrail is the onboarding and document source of truth. Required documents, review status, expirations, and completion state must be verified before operational readiness.

Workforce Owns Operations

Workforce owns the operational bridge: roster state, worker readiness, timesheets, shift review, approvals, and importable work records.

Payroll Executes Downstream

Payroll is downstream execution only. Payroll should not bypass Workforce approval or PaperTrail onboarding requirements. Payroll executes approved money movement.

Documentation Controls Operations

A person is not operationally valid just because they can log in. Required documentation and workflow state determine whether the person is ready for the business process.

State Machine Integrity

Workflow transitions must be deliberate. Draft, submitted, pending review, approved, rejected, active, suspended, revoked, and completed states should not collapse into one loose status.

Security & Trust Laws

MFA Step-Up

MFA should be enforced when risk increases. Sensitive realms such as payroll, billing, identity admin, security settings, and business ownership changes may require stronger verification than normal daily use.

Trusted Devices

Trusted devices may reduce friction, but they never replace identity. Device trust is context, not ownership. Dangerous actions can still require fresh verification.

Operational Friction Balance

Security must protect the platform without making real-world operators fight the system every day. Trusted context should reduce friction while sensitive actions remain protected.

Shared Infrastructure Laws

Shared Mail Helpers

Controllers should not build operational email HTML directly. Invitations, approvals, MFA, receipts, invoices, and notifications should use shared OhioMade mail helpers.

Shared Assets

Apps should use shared symlinked assets where possible: OhioMade CSS, app JavaScript, iOS hardening, icons, and shared shell behavior.

Shared Shell

App pages should follow the shared OhioMade shell pattern: consistent topbar, navigation, footer, dark UI, mobile-first spacing, and iPhone-safe interaction zones.

Theme Standard

OhioMade apps should use the platform theme baseline, including the dark theme-color standard of #050814 and consistent night-mode surfaces.

Icon System

Icons should come from the shared sprite system when possible. App UI should not drift into random icon sets, broken dimensions, or inconsistent SVG behavior.

Mobile Reality

OhioMade must work from an iPhone. Pages should be copy-paste friendly, touch-safe, readable, and avoid desktop-only assumptions.

Data & Audit Laws

Document Separation

Onboarding evidence should be separate from generic business archive files. Compliance documents need review state, expiration, completion logic, and stricter access rules.

Archive Separation

Business archive storage is not the same as onboarding verification. Invoices, licenses, media, receipts, and general uploads should not pollute document compliance workflows.

Audit Records

Operational actions should record actor, business, entity, workflow state, access rule, timestamp, and pipeline context wherever practical.

Traceability

Future reviewers should be able to answer who did what, for which business, under what authority, and through which workflow path.

Migration Safety

Legacy data may be preserved, but new pipelines should separate legacy, test, deprecated, and production-ready records clearly.

No Local Drift

Apps should not invent isolated permission systems, layout systems, audit systems, or ownership models when shared platform rules already exist.

Platform Doctrine

OhioMade identity is permanent. Business access is relational. Realm entry is not authority. PaperTrail validates readiness. Workforce owns approved work state. Payroll executes downstream. Shared infrastructure prevents drift. Audit records make actions explainable.