Outcome-resolution plane for lead-driven teams

Make late, duplicate, and corrected business outcomes usable.

FunnelSheet is designed to map permitted ad and web context to an authoritative business record, record timing and provenance, and prepare a bounded signal for the system that needs it. Apointoo owns the first workflow's business ledger; ClickHouse/ClickStack owns event telemetry; Langfuse owns agent traces.

Request an outcome diagnosticSee the illustrative Apointoo flow

Architecture/source documented · outcome runtime not verified

  1. Permitted contextHost capture
  2. Business recordApointoo
  3. Resolution boundaryFunnelSheet
  4. Bounded signalApproved consumer

01 / ownership

Keep every system in its lane.

The outcome path becomes safer when source context, business truth, telemetry, and agent traces are named separately.

  1. Source
    Permitted ad/web context
    Owner
    Host/GTM or approved capture path
    State
    Source/documentation only until runtime test
    Destination
    Input to the approved workflow, not business truth
  2. Source
    First workflow lead/contact/appointment record
    Owner
    Apointoo
    State
    Authoritative business ledger by project decision
    Destination
    Input to intended reconciliation
  3. Source
    Timing, duplicate, correction, provenance decision
    Owner
    FunnelSheet intended boundary
    State
    Runtime not verified; show as contract/illustration
    Destination
    Approved consumer only after verification
  4. Source
    Event telemetry
    Owner
    ClickHouse/ClickStack
    State
    Separate ownership boundary
    Destination
    Telemetry queries/observability
  5. Source
    Agent trace
    Owner
    Langfuse
    State
    Separate ownership boundary
    Destination
    Trace/evaluation systems

02 / state

A late result is a state change, not a new source of truth.

This is the intended sequence for timing, duplicate, and correction decisions. It remains an illustration until a permitted fixture and runtime path are verified.

  1. Input received

    Captured

    Permitted context enters the approved workflow.

  2. Awaiting context

    Pending / maturity window

    The workflow keeps timing visible while the business record matures.

  3. Review rule

    Duplicate or correction check

    The intended boundary checks whether a later record changes the interpretation.

  4. Decision state

    Resolved outcome or needs-review decision

    The contract distinguishes a usable resolution from a case that needs review.

  5. Policy-gated

    Bounded handoff

    Only an approved, bounded signal is prepared for its consumer.

03 / first workflow

Illustrative Apointoo workflow

Source fields shown, runtime not verified. The visual names fields and boundaries without exposing a customer record or claiming a successful reconciliation.

contract / illustrative

Field labels

  • formId
  • issue
  • website: neutral placeholder
Source: approved Apointoo field labels. Owner: Apointoo schema boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.
contract / illustrative

Context labels

  • attribution
  • utm_source
  • utm_medium
  • utm_campaign
Source: site-captured context labels. Owner: host capture boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.
contract / illustrative

Consent labels

  • adStorage
  • analyticsStorage
  • adUserData
  • adPersonalization
  • capturedAt
  • source
Source: approved consent labels. Owner: host consent boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.
contract / illustrative

Submission field

  • submissionId: field name only
Source: submissionId field name only, with no value. Owner: Apointoo workflow boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.
contract / illustrative

Timing labels

  • capturedAt
  • pending
  • duplicate check
  • correction check
Source: timing and provenance labels only. Owner: intended FunnelSheet boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.
contract / illustrative

Linkage label

  • approved non-PII linkage label only
Source: approved non-PII linkage label only, with no identifier. Owner: intended FunnelSheet boundary. State: illustrative contract; runtime not verified. Destination: no destination claimed.

04 / bounded delivery

A signal leaves the boundary only after policy says it may.

The intended handoff is deliberately narrow. Source code, a data layer, a 202 response, or a route response alone is not evidence that a destination accepted a signal.

Intended boundary · runtime not verified

  1. Resolved business outcomeFunnelSheet boundary
  2. Approved policy checkConsent and destination rules
  3. Approved destinationGeneric consumer

05 / method

Five steps to make the next decision safer.

  1. Find the break

    Diagnose

    Find where source, owner, state, or destination diverge.

  2. Name the contract

    Map

    Name the permitted fields and authoritative business record.

  3. Apply the rules

    Resolve

    Apply timing, duplicate, correction, and provenance rules.

  4. Gather evidence

    Verify

    Check source, owner, state, destination, consent, and runtime evidence.

  5. Stay bounded

    Hand off

    Prepare only the bounded signal an approved consumer can use.

Verify means evidence, not a visual check or a green build.

06 / questions

Boundaries before implementation.

Is FunnelSheet another dashboard?

No. FunnelSheet is intended as an outcome-resolution boundary between permitted context and an authoritative business record, not as a generic dashboard or replacement data foundation.

Does it replace Apointoo, a CRM, GA4, or GTM?

No. Apointoo remains the first workflow's business ledger. Existing CRM, GA4, and GTM systems keep their own roles; FunnelSheet is designed to make their boundaries explicit.

What happens when an outcome arrives late, twice, or corrected?

The intended contract names a pending window, duplicate or correction check, and either a resolved outcome or a needs-review decision. Runtime behavior still needs a permitted fixture and verification.

What does ClickHouse/ClickStack own? What does Langfuse own?

ClickHouse/ClickStack owns event telemetry and observability signals. Langfuse owns agent traces, prompts, models, scores, and evaluations. Neither is the business ledger or FunnelSheet's resolution boundary.

Can it send signals to ads, websites, or agents?

It may prepare a bounded signal for an approved consumer after policy and destination checks. No provider acceptance or live delivery is claimed here.

What is proven today and what is still illustrative?

The product boundary, source material, and intended architecture are documented. The outcome runtime, destination acceptance, and production resolution path are not verified.

What data is allowed into the workflow and where does PII stay?

Only approved field and context labels belong in the public workflow. This page shows no PII or raw identifiers; the fixture owner must approve the permitted data path before runtime claims are made.

What does the /contact form do after submission?

It opens the current contact intake. The source uses a mailto handoff, so no CRM submission, acknowledgement, response time, or delivery result is claimed.

07 / next step

Request an outcome diagnostic.

Open the contact intake to describe where the click, lead, appointment, or later record stops agreeing. The current intake is not a confirmed CRM submission.

Request an outcome diagnostic

Architecture/source documented · outcome runtime not verified