§ 01 · THE PLATFORM FIG. P-00 — OPERATING LAYER

The operating layer for intelligent buildings.

ARMS connects the signals, rules, people, systems, workflows, and records that make a building work — into one controlled operating layer that understands what is happening, sends the right action, verifies the work, and proves every step.

Model
Know · Run · Verify
Loop
Signal → Action → Proof → Memory
Posture
Configurable · governed · audit-signed
§ 1.0 · WHAT ARMS CONNECTS FIG. P-01 — INPUTS

Every input becomes part of the operation.

Most systems store these inputs separately — an inbox here, a sensor dashboard there, a folder of documents somewhere else. ARMS treats them as signals in one operating layer.

Email
Voice calls
Forms
Staff app activity
Documents
IoT sensors
Cameras
Access control
Payments
Bookings
Resident app
Vendor updates
Webhooks
External systems
Calendar events
Field signals
§ 1.1 · THE OPERATING MODEL FIG. P-02 — KNOW / RUN / VERIFY

Know what is happening. Run what happens next. Verify every step.

01
Know

ARMS senses and understands what is happening.

It classifies messages, evaluates documents, interprets sensor readings, analyzes field activity, detects patterns, and understands operational context — reading signals together instead of as separate records.

02
Run

ARMS acts through controlled workflows.

It creates tasks, routes work, sends messages, drafts replies, starts calls, schedules bookings, generates documents, triggers follow-ups, updates records, and operates connected systems.

03
Verify

ARMS proves what happened.

Every consequential action can be checked, staged, approved, logged, and exported — so completion is evidence, not a claim, and the trail is ready for managers, boards, insurers, and audits.

§ 1.2 · CONTROLLED EXECUTION FIG. P-03 — COMPARISON

Not fixed modules. Not unbounded agents. Controlled execution.

Traditional software is rigid. Open-ended agents can be unpredictable. ARMS breaks operating processes into clear steps — collect, evaluate, apply policy, route, approve where needed, act, notify, update records, and prove what happened.

Traditional Software
  • Fixed modules
  • Slow to change
  • Manual handoffs
  • After-the-fact reporting
Open-Ended Agents
  • Flexible but unpredictable
  • Harder to price
  • Harder to govern
  • Harder to prove
ARMS
  • Configurable workflows
  • Defined steps & known costs
  • Human approval where needed
  • Complete audit trail
§ 1.3 · CONFIGURATION, NOT CUSTOM SOFTWARE FIG. P-04 — NO-ROADMAP

Available by configuration, not as a future build.

M-CONFIG · Operating Layer

Most platforms treat a client-specific operating need as a feature request that joins a roadmap. ARMS treats it as a workflow. When the trigger, data source, decision logic, and action endpoint already exist, ARMS can assemble the process on the operating layer — and refine it live.

FIG. P-04A — EXAMPLE PROCESSES
Resident request triage Vendor dispatch Arrears outreach Insurance expiry Missed-patrol escalation Party-room closeout Leak response Application intake Document compliance
§ 1.4 · FIELD CONFIRMATION FIG. P-05 — PROOF OF PRESENCE

Verified on site — not only managed from a dashboard.

Run · Verify

ARMS connects the field to the operating layer. Staff activity is tied to the physical location where it happened, using location, checklists, timestamps, photos, video, QR/NFC, BLE, motion, and signal data. The worker can't simply check a box from anywhere.

Proof-of-presence Path-traversal verification Location-based tasks Dynamic checklists Photo & video evidence Arrival & answer timestamps Offline capture Round analysis
FIG. P-05A — CONFIRMATION TRACE
09:01TASK-0431 Dispatched · Mechanical Rm SENT
09:04GEO Arrived on site · BLE VERIFIED
09:09CHK Checklist 4/4 · photo CAPTURED
09:12TASK-0431 Closed · evidence saved SIGNED
§ 1.5 · INTEGRATIONS & MCP FIG. P-06 — CONNECTED

Connect the systems you already use.

Make them part of the operation

Once a system is connected, its data becomes signal and its functions become actions ARMS can govern. Deploy ARMS as the complete operations platform — or as the intelligence layer over the systems you already own.

MCP serverAPIsWebhooksEmailFile intake Calendar syncPayment eventsSensor eventsTelephonyDB lookups
§ 1.6 · GOVERNANCE & PROOF FIG. P-07 — TRUSTED

Automation is only useful if it can be trusted.

Hold · Stage · Approve · Log

ARMS can hold, stage, approve, escalate, or log every consequential action. Sensitive actions — refunds, identity changes, access changes, legal replies, vendor dispatch, payment adjustments — can require human review before they run.

Approval matrices Risk-based escalation Action staging Human handoff Decision logs Identity on every action Exportable audit trail Evidence packs
FIG. P-07A — EVIDENCE RECORD
Trigger field signal received LOGGED
Data used sensor + history + rule CITED
Decision AI output + policy check PASS
Approval human review · J. Lee SIGNED
Outcome action taken + timestamp CLOSED
§ 1.7 · COMPOSED WORKFLOWS FIG. P-08 — RUN TOGETHER

The real value appears when capabilities run together.

Featured · scheduled intelligence

Weekly Sales Activity Report

A weekly time trigger gathers this week's CRM activity and the prior week alongside it, an AI layer writes a grounded narrative (rankings, momentum, at-risk prospects, coaching actions), a deterministic layer renders the exact tables, and the combined report is emailed to ownership — analysis you can read, numbers you can trust.

Weekly trigger Gather (this + prior week) AI analysis · grounded Deterministic tables Email · audited
Sensor · vendor · resident

Leak to Resolution

A leak sensor fires, ARMS evaluates severity, notifies staff, dispatches a vendor, updates affected residents, requires completion proof, and logs the evidence.

Sensor fires Severity Dispatch Notify residents Evidence pack
Email · routing · SLA

Resident Request to Vendor and Back

A resident email is classified, matched to the unit, routed to a vendor, updated back to the resident, tracked by SLA, and closed with proof.

Email Classify + match Vendor route Resident update Closed · proof
Field · escalation · risk

Missed Patrol to Accountability

A missed round triggers a reminder, supervisor escalation, pattern detection, risk scoring, and executive visibility.

Round missed Reminder Escalate Risk score Exec visibility
Booking · payment · closeout

Paid Booking to Closeout

A booking, payment, deposit, security notification, cleaning task, damage inspection, refund approval, and closeout report all run together.

Booking + deposit Cleaning task Inspection Refund approval Closeout report
§ 1.8 · DELIVERY FIG. P-09 — SERVICE PARTNER

Configured to your policies — not the other way around.

01

Configure

Workflows reflect your operating procedures, roles, rules, and proof requirements.

02

Connect

Email, sensors, access control, payments, and external systems join the operating layer.

03

Govern

Approval checkpoints, role controls, and audit logging are set where the stakes demand them.

04

Run & refine

Workflows run live and are refined as operations change — no roadmap wait.

§ NEXT · WORKING SESSION

Bring us the process
your software can't handle.

If it can be described as inputs, rules, decisions, approvals, actions, and records, ARMS can usually turn it into a governed workflow. Bring a building, a problem, and an hour.

CONFIGURABLE WORKFLOWS HUMAN APPROVAL WHERE NEEDED COMPLETE AUDIT TRAIL