How MobileFlow works
Say a program pays for shared trips to a campus. Arcus looks at the evidence for a trip, checks it against the program's written rule and returns a decision with its reason, called an outcome receipt. A denial carries its reason too. Hytch calls Arcus for an arrival, a shared trip or a safe ride home. Tally calls it before a promoter is credited for a check-in. A verified outcome shows that something happened under the rule. It does not claim the program caused it.
Evidence → the program's written rule → a decision with its reason → payment, if the rule allows it → a receipt → a report in aggregate
Verification establishes that a qualifying event happened under a stated rule. It does not establish that a program caused the event (that question needs its own evidence and its own method). Thus Arcus reports what it can stand behind and labels the rest.
Calls Arcus when a program needs an arrival, a shared trip or a safe ride verified.
Visit HytchOwns the engine: evidence ingestion, policy evaluation, verified facts, reward-capacity accounting, denial reasons, outcome receipts and aggregate reporting.
Visit ArcusCalls Arcus to verify check-ins and attendance before a promoter is credited or a reward is released.
Visit Tally