InboundTC Product Document

Product Name

InboundTC

Full Name

Inbound Traffic Control

Product Type

Business application

Product Category

Inbound information control Message triage Entity-centered communication management Agent-assisted routing and assessment

Product Summary

InboundTC is an application for managing inbound information before it reaches human attention.

The application allows a user to create an account, define one or more Entities, register accepted inbound channels, authorize publishers, receive inbound events, resolve each event to the correct Entity, retrieve supporting information, assess the inbound activity, and route it to the correct workflow.

InboundTC begins with the Entity.

The Entity is the thing inbound activity belongs to.

Examples include a person, company, brand, department, team, product, service, application, or event.

InboundTC does not replace email systems, phone systems, QR systems, SMS providers, social platforms, website forms, or workflow tools.

InboundTC sits upstream of those systems and determines:

Who owns this inbound activity?
What channel did it arrive through?
What should happen next?

Product Purpose

InboundTC exists to ensure inbound information is not lost across disconnected channels.

Organizations receive information through email, phone, SMS, web forms, QR scans, social platforms, calendar systems, and third-party tools.

Each channel manages its own activity.

No central system understands the complete inbound relationship.

InboundTC solves this by creating a common control layer for inbound activity.

Core Problem

Most organizations do not suffer from a lack of information.

They suffer from inbound information arriving through too many disconnected channels.

Examples:

Email arrives in one system.
Phone calls arrive in another.
SMS messages arrive elsewhere.
Website forms arrive elsewhere.
QR code scans are tracked separately.
Social media activity remains locked inside external platforms.
Calendar activity is treated as scheduling, not relationship activity.

Each channel sees only its own activity.

Humans become the integration layer.

InboundTC moves upstream from this model.

It captures inbound activity as events, resolves the activity to an Entity, retrieves supporting information, assesses priority and meaning, and routes the activity for action.

Core Thesis

InboundTC is not a CRM.

InboundTC is not an inbox.

InboundTC is not a call center system.

InboundTC is not a marketing automation platform.

InboundTC is the control layer responsible for understanding inbound activity before it enters a workflow.

Primary User

The first user is a human who creates an InboundTC account.

The human administers one or more Entities.

The human is not automatically the Entity.

Example:

Account Owner
    Richard Reukema

Managed Entity
    BackTheApp.software

First Application Use Case

InboundTC itself will be entered into BackTheApp as a new application in the production list.

BackTheApp will track the development of InboundTC.

InboundTC will later process inbound activity for BackTheApp and other Entities.

Core Domain Model

Account

An Account represents the human or organization administering one or more Entities.

Account
    AccountId
    AccountName
    OwnerUserId
    Status
    CreatedAt

Entity

An Entity is the thing inbound activity belongs to.

Entity
    EntityId
    AccountId
    Name
    EntityType
    Description
    PrimaryUrl
    Status
    CreatedAt

Entity examples:

BackTheApp.software
The Empowered Customer
Phoenix Business Solutions
Richard Reukema
Support Department
Sales Team
Product Team
InboundTC

Entity types:

Person
Company
Brand
Department
Team
Product
Service
Application
Event

The EntityId is the internal system identity.

Names, URLs, email addresses, phone numbers, handles, QR keywords, and subscription paths are not Entity identity.

They are used to associate inbound activity with an Entity.

Channel

A Channel is an inbound path type accepted by InboundTC.

InboundTC defines the channels it accepts.

Examples:

Email
SMS
Phone
QRIntent
WebsiteForm
LinkedIn
TikTok
Instagram
YouTube
Calendar
Webhook
Subscription

Each Channel defines the information required for InboundTC to process inbound activity against an Entity.

Channel Identifier

A Channel Identifier is the channel-specific value used to associate inbound activity with an Entity.

Examples:

Channel = Email
Identifier = support@backtheapp.software

Channel = SMS
Identifier = +1-800-555-1234

Channel = QRIntent
Identifier = REVEAL

Channel = Subscription
Identifier = signalweaver://intentcapture/qr-intent-declared

The Channel defines the type of inbound path.

The Identifier defines the specific path within the Channel.

Entity Channel

An Entity Channel maps an Entity to a Channel and Channel Identifier.

EntityChannel
    EntityChannelId
    EntityId
    ChannelType
    ChannelIdentifier
    Status
    CreatedAt

Example:

Entity
    BackTheApp.software

EntityChannel
    ChannelType = Email
    ChannelIdentifier = support@backtheapp.software

Example:

Entity
    BackTheApp.software

EntityChannel
    ChannelType = Subscription
    ChannelIdentifier = signalweaver://intentcapture/qr-intent-declared

A Subscription is one Channel Type defined by InboundTC.

Publisher

A Publisher is a system that observes inbound activity and reports an inbound fact.

Examples:

IntentCapture
Gmail Agent
Outlook Agent
Website Agent
Calendly Agent
Twilio Agent
LinkedIn Agent

The Publisher is metadata on the inbound message.

The Publisher does not define business ownership.

The Publisher does not own the Entity.

The Publisher reports an observed fact.

Inbound Message

An Inbound Message is the normalized record created by InboundTC after receiving and resolving an inbound event.

InboundMessage
    MessageId
    EntityId
    ChannelType
    ChannelIdentifier
    PublisherId
    CorrelationId
    ObservedAt
    ReceivedAt
    SourceReference
    Status

PublisherId is provenance metadata.

CorrelationId allows InboundTC to retrieve additional information from the publisher.

SignalWeaver Event

SignalWeaver carries the fact that inbound activity was observed.

The event should remain thin.

Example:

{
  "eventType": "InboundActivityObserved",
  "publisherId": "intentcapture",
  "channelType": "Subscription",
  "channelIdentifier": "signalweaver://intentcapture/qr-intent-declared",
  "correlationId": "intent-abc-123",
  "observedAt": "2026-06-07T10:15:00Z"
}

SignalWeaver does not interpret the event.

SignalWeaver does not enrich the event.

SignalWeaver delivers the event.

Publisher Retrieval

A Publisher must expose a retrieval endpoint or MCP tool.

Example:

getInboundActivity(correlationId)

InboundTC uses the CorrelationId to retrieve source details.

Examples by channel:

Email retrieval:

From
To
Subject
ReceivedAt
BodyPreview
Headers
Attachments

QRIntent retrieval:

PhoneNumber
Keyword
Subject
Campaign
Artifact
ScannedAt

Calendar retrieval:

Invitee
Organizer
MeetingTitle
StartTime
EndTime
CalendarId

Processing Flow

Publisher observes inbound activity
        ↓
Publisher creates CorrelationId
        ↓
Publisher raises SignalWeaver event
        ↓
InboundTC receives event
        ↓
InboundTC resolves Entity using ChannelType and ChannelIdentifier
        ↓
InboundTC creates InboundMessage
        ↓
InboundTC retrieves source details using CorrelationId
        ↓
InboundTC enriches message
        ↓
InboundTC assesses message
        ↓
InboundTC routes message
        ↓
InboundTC updates Entity timeline

Entity Resolution

InboundTC resolves an Entity by matching:

ChannelType
ChannelIdentifier

against registered EntityChannel records.

Example:

ChannelType = Email
ChannelIdentifier = support@backtheapp.software

resolves to:

Entity = BackTheApp Support

Example:

ChannelType = Subscription
ChannelIdentifier = signalweaver://intentcapture/qr-intent-declared

resolves to:

Entity = BackTheApp.software

PublisherId is recorded as provenance.

PublisherId is not the primary Entity resolution key unless the Channel contract requires it.

Channel Contracts

InboundTC defines a contract for each supported Channel.

Each Channel contract defines:

ChannelType
Required event fields
Required retrieval fields
Validation rules
Entity resolution rules
Assessment eligibility
Routing eligibility

Example:

ChannelType = Email

Required event fields
    ChannelType
    ChannelIdentifier
    PublisherId
    CorrelationId
    ObservedAt

Entity resolution
    Match ChannelType and ChannelIdentifier to EntityChannel

Required retrieval fields
    From
    To
    Subject
    ReceivedAt
    BodyPreview

Example:

ChannelType = QRIntent

Required event fields
    ChannelType
    ChannelIdentifier
    PublisherId
    CorrelationId
    ObservedAt

Entity resolution
    Match ChannelType and ChannelIdentifier to EntityChannel

Required retrieval fields
    PhoneNumber
    Keyword
    Subject
    Campaign
    Artifact
    ScannedAt

Assessment

Assessment occurs after Entity resolution and source retrieval.

Assessment determines:

Importance
Urgency
Intent
Trust
Relationship context
Required action
Suggested routing

Assessment may use AI.

Assessment does not execute destination workflows directly.

Assessment produces classification, context, and recommended action.

Routing

Routing applies configured rules.

Routing should be deterministic.

Example:

Assessment
    Intent = Sales Inquiry
    Priority = High
    Confidence = 92%

Routing Rule
    Send to Sales Qualification Workflow

Destination workflow examples:

BackTheApp idea intake
Customer support
Sales qualification
Recruiting
Membership enrollment
Event registration
Product feedback

Entity Timeline

InboundTC maintains a timeline for each Entity.

Example:

2026-06-07
QR Intent Declared

2026-06-07
Idea Intake Started

2026-06-07
Idea Submitted

2026-06-08
Discovery Call Booked

2026-06-10
Workspace Created

The timeline records inbound messages, assessments, routing decisions, and outcomes.

MVP

Scope

MVP

Goal

Create the first working version of InboundTC where a user creates an account, creates an Entity, registers channels, receives SignalWeaver events, resolves messages to the Entity, retrieves source details, and displays the Entity timeline.

MVP

Features

Create account
Create Entity
Define supported Channel Types
Register Entity Channels
Register Publisher metadata
Receive SignalWeaver event
Resolve event to Entity
Create InboundMessage
Retrieve source detail using CorrelationId
Display Entity inbox
Display Entity timeline
Route to simple workflow queue

MVP

Channel Types

Subscription
QRIntent
Email
Webhook

MVP

Publishers

IntentCapture
Gmail Agent
Website Agent

MVP

Screens

Account Dashboard
Entity List
Entity Detail
Entity Channel Setup
Publisher Setup
Inbound Message List
Inbound Message Detail
Entity Timeline
Routing Rule Setup

Non-Goals For MVP

InboundTC will not replace Gmail.

InboundTC will not replace a CRM.

InboundTC will not replace a call center.

InboundTC will not directly process social media platform messages in the MVP.

InboundTC will not execute destination workflows in the MVP.

InboundTC will not attempt full identity correlation in the MVP.

InboundTC will not store every source payload permanently unless required by the Channel contract.

Ownership Boundaries

InboundTC Owns

Account
Entity
Channel definitions
EntityChannel mappings
InboundMessage records
Entity resolution
Assessment
Routing rules
Entity timeline
Relationship history

Publisher Owns

Source channel observation
CorrelationId creation
Source data retrieval
Publisher event creation
Source-specific payload

SignalWeaver Owns

Publisher registration
Subscriber registration
Event transport
Delivery rules
Event delivery status

Destination Workflow Owns

Business process execution
Task completion
Case handling
Software production
Sales workflow
Support workflow
Recruiting workflow

Initial BackTheApp Entry

Application Name

InboundTC

Application Description

InboundTC is an inbound traffic control application that receives inbound events from publishers, resolves each event to the correct Entity using channel and identifier mappings, retrieves supporting information using a correlation id, assesses the inbound activity, routes it to the correct workflow, and maintains an Entity timeline.

Business Problem

Inbound information arrives across too many disconnected systems. Email, phone, SMS, QR scans, forms, social platforms, calendars, and webhooks each manage their own activity. No central system understands which Entity owns the activity, how it relates to previous activity, or what should happen next.

Business Outcome

InboundTC reduces the time between inbound activity and informed action.

First Development Objective

Build the foundation for Entity creation, Channel definition, EntityChannel mapping, Publisher registration, SignalWeaver event intake, InboundMessage creation, and Entity timeline display.

First Vertical Slice

Process a QRIntent event from IntentCapture through SignalWeaver into InboundTC.

The flow:

IntentCapture observes QR intent
        ↓
IntentCapture publishes SignalWeaver event
        ↓
InboundTC receives event
        ↓
InboundTC resolves ChannelType and ChannelIdentifier to Entity
        ↓
InboundTC retrieves details using CorrelationId
        ↓
InboundTC creates InboundMessage
        ↓
InboundTC updates Entity timeline

Product Success Criteria

InboundTC succeeds when it reliably answers:

Who owns this inbound activity?
What channel did it arrive through?
What should happen next?

The product succeeds when an Entity owner sees inbound activity across channels in one coherent timeline.

Final Product Principle

InboundTC begins with an Entity.

Channels define how inbound activity arrives.

Identifiers define where within the channel the activity occurred.

Publishers report inbound facts.

SignalWeaver carries those facts.

InboundTC resolves, retrieves, assesses, routes, and tracks the activity.