MDX Limo
Loops

1) Core thesis

  • The primary problem: humans and AI do not share a provable definition of “done”
  • The consequence: assistants simulate progress, but users cannot delegate responsibility
  • The solution: a system that represents outcomes as claims about reality and closes them only via evidence or explicit human confirmation

2) Canonical definitions

  • Loop: a verifiable claim about the future that stays open until reality proves it true or a human explicitly confirms it
  • Closure: the set of conditions that must be satisfied to mark a loop closed
  • Signal: an immutable fact emitted by integrations, user actions, or systems of record
  • Action: an attempt to move a loop toward closure
  • Contradiction: a signal that invalidates closure and reopens the loop

3) Product vision

  • One “truth layer” above all tools that answers: what is still not actually done?
  • The app becomes the canonical place to see unresolved reality
  • AI helps propose actions and definitions; the system proves closure; humans arbitrate ambiguity
  • Expansion path: from email + calendar to “any domain” via templates + sensors + confirmation

4) Principles and non-negotiables

  • Reality closes loops, not AI
  • Closure must be auditable (who/what/why/evidence)
  • Evidence-closed preferred, asserted-closed allowed, AI-only closure prohibited
  • Contradictions reopen loops automatically
  • High-stakes loops require stricter closure and higher approval thresholds
  • Extensibility must not degrade truthfulness

5) Conceptual model

  • Goals describe “why” (optional)
  • Loops define “what must become true” (strict)
  • Actions attempt to make it true
  • Signals prove whether it happened

6) Object model

6.1 Minimal Loop schema

  • Fields

    • id
    • objective (human-readable claim)
    • status (OPEN, IN_PROGRESS, BLOCKED, AT_RISK, CLOSED, REOPENED, ABANDONED)
    • closureSpec (how done is proven)
    • context (people, threads, events, docs, etc.)
    • risk (low/med/high), external boolean, irreversible boolean
    • createdAt, updatedAt, dueBy optional

6.2 ClosureSpec (constrained, machine-evaluable)

  • mode: evidence | asserted
  • conditions: list of allowlisted conditions
  • requiresUserApproval boolean
  • confidence (informational, never authoritative)
  • createdBy: system | ai | user
  • versioning

6.3 Signal (facts)

  • id, loopId
  • type (open string)
  • source (integration/system/user/agent)
  • payload (optional)
  • timestamp
  • immutability

6.4 Action (attempts)

  • id, loopId
  • type
  • preview / proposed change
  • requiresApproval
  • status: proposed/approved/executed/failed
  • executedAt

6.5 DecisionTrace (audit + learning)

  • proposed action, user response (approved/edited/rejected)
  • diff or notes
  • timestamp
  • ties to outcomes for learning

6.6 Optional Goal object

  • flexible tracking layer
  • can spawn loops (templates or manual)

7) Closure semantics and risk control

7.1 Two closure modes

  • Evidence-closed: conditions satisfied by signals
  • Asserted-closed: explicit user confirmation (optionally with proof)

7.2 “Closure is a fact” enforcement

  • Loops cannot close without:

    • required evidence signals, or
    • explicit confirmation condition

  • No “AI thinks it’s done”

7.3 Contradiction and auto-reopen

  • Define reopen signals per loop type/template
  • Automatic transition: CLOSED → REOPENED on contradiction
  • Record contradiction evidence and cause

7.4 Risk gating rules

  • If external or irreversible or high-risk:

    • prefer evidence-closed only
    • require HITL for actions
    • require explicit confirmation if evidence incomplete

  • Low-risk internal loops may allow looser confirmation, but still auditable

8) AI’s role (strictly scoped)

  • AI may:

    • detect candidate loops
    • propose closure specs (in constrained DSL)
    • propose next actions
    • summarize why a loop is open
    • rank risk/priority and detect stalling

  • AI may not:

    • mark loops closed
    • suppress contradictions
    • invent evidence
    • silently resolve ambiguity

  • The system, not AI, is the authority on closure state

9) Templates: how the system becomes universal

9.1 LoopTemplate

  • type (string namespace)

  • required context keys

  • default risk profile

  • closure spec

  • reopen rules

  • suggested actions

  • examples:

    • scheduling.email
    • followup.after_meeting
    • contract.signature
    • invoice.paid
    • pr.merged

9.2 Template rollout safety ladder

  • Observe: compute “would close” only
  • Recommend: suggest closure, require approval
  • Enforce: auto-close only when evidence-based and stable
  • Graduation gates based on metrics (false closures, reopens)

10) Integrations as sensors (not features)

10.1 Integration selection principle

  • Integrations are valuable only if they emit authoritative closure signals

10.2 Integration tiers

  • Tier 1: Email, Calendar
  • Tier 2: Docs/Drive + e-signature, Payments/Invoices
  • Tier 3: Issue tracking (GitHub/Linear/Jira), CRM
  • Tier 4: External reality feeds (shipping, support tickets, domain-specific webhooks)

10.3 Signal taxonomy design

  • Keep signals open-string but governed
  • Canonical naming conventions
  • Provenance requirements (where signal came from, when, and how derived)

11) App UX concept

11.1 Primary screen: Open Loops

  • A list of unresolved claims about reality

  • Each item shows:

    • statement of outcome
    • waiting-on (you/them/system/time)
    • source of truth (email/calendar/etc.)
    • risk indicator

11.2 Loop detail view

  • Evidence view: signals that exist vs missing
  • Context view: relevant thread/event/doc
  • Suggested action view: what to do next
  • Audit view: how decisions were made

11.3 Closure UX

  • Evidence-closed: disappears automatically when conditions met
  • Asserted-closed: user confirms with optional proof note/link
  • Reopen UX: loop reappears with “why it reopened” and the contradictory signal

11.4 Interaction model

  • No checkboxes as default behavior
  • “Silence is the reward”: absence indicates truly done
  • “Why is this open?” is the core tap behavior

11.5 Notifications

  • Only for:

    • new high-risk loops
    • loops that became at-risk
    • contradictions/reopens
    • approval requests (write operations)

12) System behavior and lifecycle

  • Creation

    • manual creation
    • inference from integrations
    • template-driven creation from events (meeting ended → follow-up loop)

  • Progression

    • actions proposed and executed
    • state transitions based on evidence and waiting states

  • Closure

    • evidence or assertion
    • full record of closure proof

  • Reopen

    • contradiction arrives
    • re-evaluation and escalation

13) Prioritization and ranking

  • Ranking model inputs

    • risk level
    • person importance (later)
    • time sensitivity (dueBy)
    • stalling duration
    • irreversibility/external visibility

  • Views

    • “At Risk”
    • “Waiting on Me”
    • “Waiting on Others”
    • “This week”

14) Trust, safety, and accountability

  • Read vs write boundaries (if actions exist)

  • HITL requirements for high-stakes actions

  • Deterministic guardrails around:

    • wrong recipient/thread/account
    • irreversible ops
    • ambiguity resolution

  • Audit log requirements:

    • what was proposed
    • what was approved/edited
    • what was executed
    • what outcome occurred

  • Reversibility patterns:

    • draft instead of send
    • tentative holds instead of booking
    • confirm before notifying attendees

15) Metrics that prove it works

  • Core trust metric: “If it’s not on the list, it’s actually done”

  • Operational metrics

    • false closure rate (closed then reopened)
    • auto-reopen rate
    • asserted vs evidence closure mix
    • time-to-close by loop type
    • stalling rate and resolution rate
    • user correction rate on actions
    • notification-to-resolution conversion

  • Product metrics

    • loops closed per week per user
    • retention correlated with loop closure volume
    • trust resets and causes

16) Expansion roadmap

  • Phase 1: Email + calendar loops with rock-solid closure
  • Phase 2: Templates + observe/recommend rollout
  • Phase 3: Docs/signature and payments sensors
  • Phase 4: Domain-specific sensors + webhooks
  • Phase 5: Autonomy expansion gated by measured correctness

17) Technical architecture (high level)

  • Ingestion layer for integrations (webhooks + polling where needed)

  • Normalization layer (thread/event identity resolution)

  • Loop engine

    • creation rules
    • closure evaluation
    • contradiction detection
    • state transitions

  • Storage

    • loops
    • signals
    • actions
    • decision traces
    • templates

  • Serving layer

    • Open Loops views
    • “why open” explanations
    • approval flows if acting is supported

18) Product positioning (internal truth)

  • Not a task manager
  • Not a productivity dashboard
  • Not a notes app
  • A system for verified follow-through and real responsibility

19) Open questions to resolve early (to avoid drift)

  • What counts as an authoritative signal in each integration?
  • What is the minimum evidence required to close each core loop type?
  • When do we allow asserted closure and what proof do we require?
  • What is the default reopen window for each loop type?
  • How do we communicate “asserted” vs “proven” without confusing users?

20) Canonical one-line definition

  • The system that gives humans and AI a shared, provable definition of “done.”
Created with MDX Limo
Loops | MDX Limo