ORsFlow White Paper

1. Executive Summary

Verified product factORsFlow is a business execution and decision system. An owner states a business outcome; ORsFlow structures where the business stands, names the primary constraint, weighs the candidate moves, selects the next best move, produces the work that move needs, tracks the real result and derives what should happen next.

Design principleThe system is built around one distinction: progress is what measured results show, not what activity suggests. Every screen, decision and number in ORsFlow is organised around that distinction.

Design principleORsFlow does not promise a specific business outcome. Results depend on execution, evidence, market conditions and the reality of the business.

2. The Business Execution Problem

Design principleSmall and growing businesses rarely lack things to do. They lack a reliable way to decide which single thing matters most now, to produce the work it needs, and to know afterwards whether it worked.

Design principleWhen effort is spread across many problems at once, none of them moves far enough to be measured, and the owner cannot tell which actions helped. The result is busy weeks and an unchanged business.

3. The Decision Gap

Design principleTask tools record what was done. Dashboards report what the numbers are. Chat assistants answer the question they are asked. None of them decides what is worth doing next for a stated outcome, explains why, and holds that decision accountable to a measured result.

Design principleThat missing link — between an outcome, a decision, the work it needs and the evidence of its effect — is the decision gap ORsFlow is designed to close.

4. ORsFlow Product Thesis

Design principleOne outcome, one primary constraint, one next move at a time, each judged by evidence rather than effort.

Design principleEvery value carries its source; owner words are never relabelled as connected data, and inferences are labelled as inferred.

Design principleWhen unsure, ask one question instead of guessing; when a goal cannot be read, open no mission.

Design principlePrepare, never act: anything that reaches the outside world stays with the owner.

Verified product factThe core engine runs with owner input alone. Connectors and the optional interpreter are additions; no core step depends on either.

5. Public Simplified Loop

Verified product factThe public loop has ten steps: Outcome → Current reality → Primary constraint → Economic case → Next best move → Work produced → Result → Momentum → Learning → Next move.

Design principleIt is the compressed explanation used for quick comprehension: on the landing page, in short content and on Today's decision chain.

6. Full Operating Loop

Verified product factThe full operating loop has fifteen steps: Outcome → Current reality → Primary constraint → Candidate moves → Economic case → Next best move → Mission → Work produced → Governed execution → Evidence → Result → Momentum → Learning → New reality → Next move.

Design principleThe two loops are not competing definitions. Every public step appears in the full loop, in the same order and with the same name; the full loop adds the steps that make execution accountable — candidate moves, mission, governed execution, evidence and new reality.

Verified product factThe Mission workspace shows the full loop as a stepper; Today shows the compressed decision chain.

7. Current Reality Model

Verified product factAn outcome is first read into a Goal Contract — metric, current value, target, direction and timeframe — which the owner confirms before any mission opens. If the goal cannot be read with confidence, no mission is created until it is confirmed.

Verified product factCurrent reality is structured into facts, calculations, inferences and unknowns, each with its source: owner-reported, connected source, calculated, inferred or system-observed. Unknowns are listed as unknowns rather than filled in.

Verified product factORsFlow does not verify an owner's numbers on its own. A number counts as verified only when an authorized connected source provides it; a typed claim of verification counts for nothing.

8. Primary Constraint

Verified product factORsFlow names one primary constraint — the condition limiting the outcome most — with a confidence level and the reason it outranks the alternatives.

Verified product factAfter every result the constraint is re-checked: it can remain, be resolved or be replaced, and the owner is told which.

9. Candidate Moves

Verified product factFor the primary constraint, ORsFlow considers several candidate moves. Candidates that are excluded remain visible with the reason for their exclusion.

Design principleShowing the alternatives is what allows an owner to judge the choice rather than accept it on faith.

10. Economic Case

Verified product factEach candidate is weighed on expected impact, the metric it should move, cost, capacity required, time to evidence, confidence and downside risk, with the evidence required and a stop condition.

Verified product factEvery level in the economic case is an estimate and is labelled as one. It is qualitative; ORsFlow makes no money forecast.

11. Next Best Move

Verified product factORsFlow selects one move and records why it outranked the others. The reasons are persisted with the decision.

Design principleThe selection is deterministic: the same reality produces the same decision, which makes every decision reproducible and auditable.

12. Mission Model

Verified product factThe selected move becomes a mission: a measurable commitment with an expected effect, thresholds for green, yellow and red, a review window and a capacity check.

Verified product factMissions count toward the plan's monthly mission allowance when they are created; reporting results does not.

13. Work Produced

Verified product factORsFlow produces the work the move needs — for example customer definitions, value propositions, offers, pricing recommendations, qualification criteria, outreach and follow-up drafts, interview guides, objection handling, demo scripts, seven-day plans, success criteria and tracking structures — saved to the workspace and tied to the mission.

Verified product factWork is produced from the owner's facts using structured templates, without a model call. Each item is labelled as produced or as needing input; a missing fact is named, never invented.

Verified product factEach item in the product shows what it is, why it was created, the mission it serves, what the owner should do with it and what will be measured.

14. Governed Execution

Verified product factORsFlow does not send, publish, spend, sign, call or email. The owner carries out every action that reaches the outside world.

Verified product factTopics such as pricing and commercial changes are marked as needing the owner's approval. Governance flags never claim legal authority and never authorize an action.

15. Evidence Model

Verified product factResults are reported by the owner in their own words, or read from a connected tool where one is authorized. ORsFlow states what it understood from a report.

Verified product factWhen a report is unclear, ORsFlow holds it and asks one question rather than guessing. Activity is recorded as activity; it is not evidence of an outcome.

16. Results

Verified product factEach result is compared with the mission's expected effect and marked green, yellow or red against its thresholds.

Verified product factOutcome achieved is recorded only when the confirmed target is met on reported evidence.

Verified product factThe results view separates activity, output, outcome and business impact. Any step without a measured result reads Not yet measured; values are never synthesized.

17. Momentum

Verified product factBusiness Momentum is derived from measured results. Completing actions does not move it.

Design principleMomentum is an authority, not a decoration: no interface element — including the Signal Orb — can change it.

18. Learning

Verified product factAfter a result, expected versus actual decides continue, change or stop, whether further investment is justified and whether an assumption changed. When a move is stopped or changed, the reallocation of effort is recorded.

Verified product factA move that failed is not chosen again for the same mission.

19. New Reality

Verified product factA result updates current reality; the constraint is re-checked and the next move is derived from the new reality. When the goal is met, no new mission is opened for it.

20. Business Memory

Verified product factEvery objective, metric, constraint, decision, move, expected and actual outcome and learning is persisted and reused by later missions.

Verified product factBusiness Memory is private to each account.

21. Optional Connectors

Verified product factConnectors let ORsFlow read numbers from tools an owner already uses, in categories such as payments, CRM, accounting, commerce, project management, communication, calendar, storage and development.

Verified product factConnectors are read-only: they do not write, send, spend or delete. ORsFlow's core loop runs fully without any connector.

22. Human Control & Governance

Verified product factThe owner confirms the goal, carries out every external action and approves governed topics. ORsFlow decides what is worth doing next and prepares the work; it does not act on the owner's behalf.

Verified product factThe Signal Orb shows one visible state vocabulary — for example Analyzing reality, Constraint found, Comparing moves, Mission active, Waiting for result, Learning and Blocked — over the product's existing state models.

Design principleThe Orb is a readout only. It does not decide, score, recommend, create evidence, alter Momentum or act. Listening appears only while a microphone is genuinely capturing.

23. Security Principles

Verified product factEvery route that returns account data re-verifies the session against the database. Account isolation has been probed in end-to-end and load tests without a cross-account leak.

Verified product factDeleting an account removes the account, its sessions and the workspace documents it owns.

Design principleORsFlow is built to make its boundaries explicit: what it decides, what it prepares, what it waits for and what it never does.

24. Illustrative Business Scenario

Illustrative exampleA design agency receives about 40 inbound leads a month and converts 1 into a client. The owner wants 4 new clients a month.

Illustrative exampleORsFlow reads the Goal Contract (new clients: 1 now, 4 targeted, monthly), structures the agency's reality and names the primary constraint: demand is not converting into buyers.

Illustrative exampleIt considers candidate moves — an entry offer, a follow-up system, and collecting loss reasons (excluded for this round, with its reason shown) — weighs each in the economic case and selects one as the next best move.

Illustrative exampleIt produces the work for that move, such as a conversion diagnosis, a value proposition and a paid pilot offer. The owner carries the work out and reports the result in plain words; ORsFlow compares expected with actual, updates Momentum, records the learning and derives the next move.

Illustrative exampleThis scenario is illustrative and is not customer data.

25. Product Boundaries

Verified product factORsFlow does not produce websites, ads, social posts, contracts, invoices or code, and it writes no work with a model.

Verified product factORsFlow cannot see anything outside itself unless the owner reports it or an authorized connector reads it.

Verified product factPlan entitlements gate volume and depth of intelligence. The core execution engine runs on every plan, including the trial.

26. Current Limitations

Verified product factORsFlow does not understand every goal wording. When it cannot read a goal, it opens no mission rather than guessing.

Verified product factFor capacity and quality constraints, playbook steps are instructions rather than produced assets.

Verified product factThe cash-flow and risk operating families are planned but not measured.

Verified product factORsFlow has not yet been proven on a real owner's business over a full loop. No customer result is claimed in this paper.

27. Product Evolution Principles

Design principleNew capability is added without weakening provenance, the owner's control or the rule that Momentum moves only with measured results.

Future directionCapturing the owner's jurisdiction so governance topics can be more specific, while still never interpreting law.

Future directionMeasuring the cash-flow and risk operating families.

Future directionBroadening the goal wordings the engine can read on its own.

Future directionRunning and publishing real owner loops, with owner consent, as evidence of how the system performs in practice.

28. Developed and Operated by Sentinel Fortune LLC

Verified product factORsFlow is developed and operated by Sentinel Fortune LLC.

Verified product factQuestions about this paper can be sent through the support routes listed in the ORsFlow Help pages.

29. Conclusion

Design principleORsFlow is designed to close the decision gap: to turn a stated outcome into one accountable move at a time, produce the work that move needs and let measured evidence — not activity — decide what happens next.

Design principleORsFlow does not promise a specific business outcome. Results depend on execution, evidence, market conditions and the reality of the business.