Meet Richard.He still builds.

MyAISpeakEasy is a Phoenix-built AI speaking and assessment presence that turns AI strategy, practical evaluation, and content-led outreach into a public website and supporting publication workflow.

AISoftwareFactory is a Phoenix-built public site for explaining AI-assisted software delivery, workflow telemetry, and production-oriented application creation.

CustomerGravity is a Phoenix-built customer acquisition application that combines form workflows, reusable SDK pieces, and integration-ready application plumbing.

ContentTraker Product Idea

Status: Business idea draft
Date: 2026-06-08
Purpose: Describe ContentTraker as a product idea, without implementation or architecture details.

One-Sentence Idea

ContentTraker is a private AI memory system that helps people preserve their work, organize it by context, and reuse it through guided conversations, reusable prompts, personas, and trusted AI access.

Product Promise

Your work should not disappear into folders, chat history, or scattered tools.

ContentTraker gives a person or team a private place to keep the work they have created, understand why it matters, and use AI to continue from that context instead of starting over.

The Problem

People create valuable knowledge every day:

• documents
• prompts
• transcripts
• drafts
• research notes
• conversations with AI
• client or project decisions
• reusable thinking patterns

The problem is not just storage. The problem is loss of context.

Files can be saved but forgotten. AI conversations can be useful but disconnected from the next project. Prompts can work once but become hard to find. A person may know they created something useful before, but not remember where it lives, why it was made, or how to reuse it.

ContentTraker exists to solve that context-loss problem.

The Product Idea

ContentTraker creates a private memory space around a person's or team's work.

Inside that space, the user can:

1. create separate workspaces for different areas of work
2. collect files, notes, prompts, transcripts, and conversations
3. organize active work into projects and threads
4. ask AI questions using saved workspace context
5. reuse prompts and personas across different kinds of work
6. connect approved AI assistants to a workspace without opening everything
7. keep a traceable record of what was created, discussed, and reused

The idea is simple: when knowledge is organized with intent, AI becomes more useful because it can work from the right memory.

Target Users

Audience	Need
Independent creators	Preserve drafts, prompts, transcripts, and creative work so they can build on it later.
Consultants and advisors	Keep client or project context separated, reusable, and searchable.
Small teams	Share a controlled memory space around active work without losing ownership or context.
AI-heavy workers	Turn useful conversations and prompts into reusable assets instead of disposable chat history.
Business owners	Maintain a private knowledge base that supports decisions, content, support, research, and planning.

AIID Token Convention

Business idea tokens use this format:

AIID-CT-{AREA}-{NNN}

These tokens identify product intent. They do not describe technical implementation.

Product Levels

AIID	Level	Used for
AIID-CT-IDEA-001	Product idea	Define ContentTraker as private AI memory for created work.
AIID-CT-ACCOUNT-001	Account	Keep the user's identity, preferences, membership, and access in one place.
AIID-CT-WORKSPACE-001	Workspace	Separate one area of work from another so context stays clear.
AIID-CT-PROJECT-001	Project	Focus activity inside a workspace around a goal, client, topic, or deliverable.
AIID-CT-THREAD-001	Conversation thread	Preserve the flow of questions, answers, decisions, and refinements.
AIID-CT-TURN-001	Conversation turn	Keep each meaningful exchange available for later review or reuse.
AIID-CT-ASSET-001	Knowledge asset	Save files, notes, prompts, transcripts, source summaries, and final outputs.
AIID-CT-PROMPT-001	Prompt library	Store reusable instructions that can be used across workspaces.
AIID-CT-PERSONA-001	Persona library	Store reusable AI communication styles for different audiences or tasks.
AIID-CT-WORKSPACE-KNOWLEDGE-001	Workspace knowledge	Let the AI answer from saved material inside one workspace.
AIID-CT-PROJECT-MEMORY-001	Project memory	Let the AI remember project conversations and decisions.
AIID-CT-MY-WORKSPACE-001	Personal realm	Let the user ask across the workspaces they are allowed to access.
AIID-CT-AGENTIC-ACCESS-001	Agentic access	Let approved external AI assistants work with a limited workspace context.
AIID-CT-TRUST-001	Trust and control	Keep private work scoped, traceable, and controlled.
AIID-CT-COMMERCIAL-001	Membership	Support a paid product boundary around valuable AI-backed capabilities.

What Each Level Means

AIID-CT-ACCOUNT-001 - Account

The account is the user's personal relationship with ContentTraker.

It is used for:

• signing in
• saving preferences
• controlling access
• connecting membership or subscription status
• deciding which workspaces the user can use

AIID-CT-WORKSPACE-001 - Workspace

A workspace is the main container for context.

It is used for:

• keeping one area of work separate from another
• storing knowledge assets
• grouping projects
• controlling who can access that work
• giving AI the right boundary for answers

Examples:

• a client workspace
• a product workspace
• a personal writing workspace
• a research workspace
• a business planning workspace

AIID-CT-PROJECT-001 - Project

A project is a focused effort inside a workspace.

It is used for:

• pursuing a specific goal
• collecting related conversations
• shaping a deliverable
• keeping work in progress organized
• preserving why decisions were made

Examples:

• create a blog post
• research a market
• prepare a client proposal
• plan a product launch
• refine a business idea

AIID-CT-THREAD-001 - Conversation Thread

A conversation thread is the story of one focused exchange with AI or another assistant.

It is used for:

• capturing questions and answers
• recording refinements
• preserving useful reasoning
• keeping project conversations traceable
• allowing the user to continue from a prior discussion

AIID-CT-TURN-001 - Conversation Turn

A turn is one message in a conversation.

It is used for:

• distinguishing what the user asked from what the AI answered
• preserving important moments in the conversation
• allowing later review of how an answer was reached
• keeping useful exchanges from being lost

AIID-CT-ASSET-001 - Knowledge Asset

A knowledge asset is any saved item that may be useful later.

It is used for:

• saving created work
• preserving source material
• keeping transcripts and notes
• storing final outputs
• giving AI material it can use when answering questions

Examples:

• article draft
• meeting transcript
• research summary
• prompt
• client note
• strategy document
• project recap

AIID-CT-PROMPT-001 - Prompt Library

The prompt library is the user's reusable instruction shelf.

It is used for:

• saving prompts that worked well
• reusing instructions across workspaces
• improving consistency
• avoiding repeated prompt writing
• turning personal methods into reusable assets

AIID-CT-PERSONA-001 - Persona Library

The persona library stores how the AI should communicate.

It is used for:

• choosing tone
• matching audience level
• setting writing style
• shaping depth of explanation
• keeping different types of work from sounding the same

Examples:

• technical advisor
• plain-language teacher
• marketing strategist
• executive summary writer
• research assistant

AIID-CT-WORKSPACE-KNOWLEDGE-001 - Workspace Knowledge

Workspace knowledge lets AI answer from saved material inside one workspace.

It is used for:

• asking about uploaded or saved material
• reusing prior work
• grounding answers in the selected workspace
• reducing generic AI responses
• keeping one workspace from bleeding into another

AIID-CT-PROJECT-MEMORY-001 - Project Memory

Project memory lets AI remember work in progress.

It is used for:

• understanding past project conversations
• finding prior decisions
• continuing from previous threads
• reducing repeated explanations
• keeping project-specific context alive

AIID-CT-MY-WORKSPACE-001 - Personal Realm

My Workspace is the user's broader personal view across authorized workspaces.

It is used for:

• asking across the user's accessible work
• finding where something was discussed or saved
• maintaining personal continuity
• connecting related ideas across separate workspaces
• supporting a private second-brain experience

AIID-CT-AGENTIC-ACCESS-001 - Agentic Access

Agentic access lets approved AI assistants work with ContentTraker safely.

It is used for:

• giving an external assistant access to a limited workspace
• capturing useful AI work back into ContentTraker
• asking questions from another tool
• creating or updating knowledge assets with user-approved scope
• avoiding full-account exposure

AIID-CT-TRUST-001 - Trust and Control

Trust and control are product requirements, not optional features.

They are used for:

• keeping work private
• enforcing workspace boundaries
• showing what happened
• supporting review and investigation
• making AI access understandable and reversible

Core User Journeys

AIID-CT-JOURNEY-001 - Start a Workspace

The user creates a workspace for a specific area of work, gives it a purpose, and begins adding projects, assets, or conversations.

Outcome: The user has a private, bounded place where related work can accumulate.

AIID-CT-JOURNEY-002 - Save Knowledge

The user saves files, notes, transcripts, prompts, or summaries into the workspace.

Outcome: The work becomes part of a reusable memory instead of staying scattered.

AIID-CT-JOURNEY-003 - Continue Work With AI

The user asks a question inside a workspace or project.

Outcome: AI responds using the right context and preserves the conversation for future use.

AIID-CT-JOURNEY-004 - Reuse a Prompt

The user saves a useful prompt and applies it again later.

Outcome: Good instructions become reusable product assets.

AIID-CT-JOURNEY-005 - Choose a Persona

The user chooses how AI should speak for a project.

Outcome: The same knowledge can be explained differently depending on audience and purpose.

AIID-CT-JOURNEY-006 - Ask Across My Work

The user asks a broader question across their authorized workspaces.

Outcome: ContentTraker helps the user find connections across separate areas of work without merging everything together.

AIID-CT-JOURNEY-007 - Connect an AI Assistant

The user allows an external AI assistant to work with a specific workspace or project.

Outcome: The assistant can help without receiving uncontrolled access to the user's whole account.

Business Requirements

AIID	Requirement
AIID-CT-REQ-001	Users must be able to separate different areas of work into workspaces.
AIID-CT-REQ-002	Users must be able to preserve conversations as reusable memory.
AIID-CT-REQ-003	Users must be able to save and reuse prompts.
AIID-CT-REQ-004	Users must be able to save and reuse personas.
AIID-CT-REQ-005	Users must be able to ask questions from workspace knowledge.
AIID-CT-REQ-006	Users must be able to ask broader questions across work they are allowed to access.
AIID-CT-REQ-007	Users must stay in control of what external AI assistants can access.
AIID-CT-REQ-008	The product must preserve trust, privacy, and traceability as core behavior.
AIID-CT-REQ-009	The product must support a paid membership boundary for valuable AI-backed use.

Non-Goals

ContentTraker is not intended to be:

• a generic public file-sharing site
• a replacement for every document management system
• an uncontrolled AI chatbot
• a public search engine for private work
• a system where every assistant can see everything
• a product that treats prompts and conversations as disposable

Success Measures

AIID	Success measure
AIID-CT-SUCCESS-001	Users can find and reuse work they previously created.
AIID-CT-SUCCESS-002	Users create workspaces for distinct contexts instead of mixing everything together.
AIID-CT-SUCCESS-003	Users ask better AI questions because relevant context is already available.
AIID-CT-SUCCESS-004	Prompts and personas are reused across multiple projects.
AIID-CT-SUCCESS-005	External AI assistants can help while staying within approved boundaries.
AIID-CT-SUCCESS-006	Users trust the system enough to save valuable work in it.

Open Business Questions

AIID	Question
AIID-CT-OPEN-001	Should the product language emphasize "private AI memory", "second brain", "workspace knowledge", or another primary category?
AIID-CT-OPEN-002	Should knowledge levels be visible to customers, or should the product describe them in plain words only?
AIID-CT-OPEN-003	Which first customer segment should the product optimize for: creators, consultants, teams, or AI-heavy business owners?
AIID-CT-OPEN-004	What is the first paid plan, and what value should it clearly unlock?
AIID-CT-OPEN-005	How much operational transparency should normal users see versus administrators?

Plain-Language Elevator Pitch

ContentTraker is a private AI memory for the work you create.

It keeps your files, prompts, transcripts, AI conversations, and project notes organized by workspace. You can ask questions from that saved context, reuse prompts and personas, and let approved AI assistants help inside clear boundaries.

The goal is simple: stop losing useful work, and stop starting over.

SnapChing is a Phoenix-maintained consumer application with evidence of production hardening, consent handling, troubleshooting, and supporting SMS workflow history.

GFS Device Init is an IoT-oriented application record for device onboarding, message handling, telemetry operations, and production support workflows.

SignalWeaver Market Value Proposition AIID Tokenized Specification v1.0

Status: Draft tokenized specification Date: 2026-06-08 Original source: 20260608-signalweaver-market-uvp.spec.original.v1.0.md Assumption source: 20260608-signalweaver-market-uvp.spec.aiid-assumptions.v1.0.md ContentTraker status: Local export only. This checkout does not have a .contenttraker project binding.

Product Purpose

SignalWeaver turns business activity into trusted signals.

It gives organizations a controlled way to publish, route, observe, and reason about cross-application events before deciding what action belongs in each participating application.

Market Position

SignalWeaver sits between technical observability and workflow automation.

It is not just a log viewer, because it works with business event contracts, publisher authority, subscriber registration, delivery, and audit evidence.

It is not a workflow engine, because subscriber applications keep ownership of business logic and local decisions.

It is the business-event intelligence rail for organizations that need evidence before action.

Unique Value Proposition

SignalWeaver's unique market value is the combination of:

• controlled publisher authority
• event contract traceability
• authorized subscriber participation
• delivery and audit evidence
• observable relationships between events
• support for agentic and AI-assisted application flows without bypassing ownership boundaries

AIID Token Registry

AIID	Kind	Title	Market Claim	Acceptance Rule
AIID-SW-UVP-001	ux-element	Market Position	SignalWeaver sits between observability and workflow automation.	The positioning statement names both contrasts and does not collapse into either category.
AIID-SW-UVP-002	ux-element	Event Blindness Problem	Customers lose context when events remain scattered or isolated.	The problem statement explains why isolated triggers and logs are not enough.
AIID-SW-UVP-003	ux-element	Understanding Before Action	SignalWeaver turns events into evidence before action.	The value claim says action is downstream of understanding.
AIID-SW-UVP-004	integration	Controlled Publisher Rail	Publishers emit approved events through a controlled route.	The claim includes publisher authority, registered event, route, delivery, and audit.
AIID-SW-UVP-005	business-rule	Signal Not Trigger	An event becomes a signal because of context, sequence, and timing.	The claim avoids presenting every event as an automatic action trigger.
AIID-SW-UVP-006	business-rule	Multiple Listeners	Different subscribers can interpret the same event flow without changing the source fact.	The record separates source event truth from subscriber interpretation.
AIID-SW-UVP-007	data-state	Event Contract Vocabulary	SignalWeaver can organize event names, versions, domains, relationships, and expectations.	The claim stays at contract level and does not interpret customer payloads.
AIID-SW-UVP-008	data-state	Audit Evidence	SignalWeaver preserves evidence of route, delivery, and observed follow-up.	The evidence claim is traceable without promising automatic resolution.
AIID-SW-UVP-009	decision	Subscriber-Owned Action	Subscribers own business execution.	The boundary statement says SignalWeaver is not the workflow engine.
AIID-SW-UVP-010	integration	Agentic Onboarding	Authorized agents can help onboard participants without bypassing control.	The claim references authorized MCP and SDK support as implementation support, not public product magic.
AIID-SW-UVP-011	ux-element	Target Market	SignalWeaver fits AI-assisted and multi-application environments.	The target market names the systems most likely to need event evidence before action.
AIID-SW-UVP-012	decision	Competitive Differentiation	SignalWeaver is distinct from logs, queues, service buses, iPaaS, and workflow engines.	The differentiation table explains what SignalWeaver adds and what it does not replace.

Tokenized Market Copy

AIID-SW-UVP-001 Market Position

SignalWeaver is the business-event intelligence rail for organizations that need to understand cross-application activity before they act.

It sits between technical observability and workflow automation. Logs can show fragments. Workflow engines can trigger action. SignalWeaver preserves the business event flow, the authorized route, and the evidence needed to decide what action should happen next.

AIID-SW-UVP-002 Event Blindness Problem

Modern applications create business events constantly, but the flow is often invisible.

A lead is submitted. An account is created. A payment starts. A subscriber receives an event. A processor finishes work. A follow-up fails.

Without a shared event trail, teams are left with scattered records and assumptions. They act on symptoms instead of the sequence that produced them.

AIID-SW-UVP-003 Understanding Before Action

SignalWeaver turns events into trusted signals.

The product value is not only that an event was published. The value is knowing what happened, who was allowed to publish it, where it was routed, who received it, what follow-up was observed, and where the chain stopped.

AIID-SW-UVP-005 Signal Not Trigger

SignalWeaver treats an event as evidence first.

An event becomes a signal when its timing, sequence, route, and relationship to other events indicate that something matters. That keeps organizations from treating every event as an automatic command.

AIID-SW-UVP-009 Subscriber-Owned Action

SignalWeaver does not replace the customer's business application.

Customer applications and subscriber services own business logic, payload interpretation, local decisions, and workflow execution. SignalWeaver owns the event contract boundary, publish authority, delivery rail, subscriber registration path, audit trail, and observable relationships between events.

Expanded AIID Records

AIID-SW-UVP-001 Market Position

kind: ux-element

screenOrWorkflow: Market introduction

actor: business or technical buyer

intent: Position SignalWeaver in the market without misclassifying it.

coreUseCase: Buyer understands that SignalWeaver is neither just logging nor workflow automation.

businessLogic: Product copy must preserve the "between observability and workflow automation" positioning.

architectureBoundary: Market-facing wording only; no runtime behavior is created.

acceptanceRule: The positioning statement names SignalWeaver as a business-event intelligence rail.

sourceReference: Local original spec Market Value Proposition; SignalWeaverLandingSite/Components/Pages/Home.razor.

threadStatus: Draft.

AIID-SW-UVP-002 Event Blindness Problem

kind: ux-element

screenOrWorkflow: Market introduction

actor: buyer or application owner

intent: Make the problem visible before discussing the solution.

coreUseCase: Customer recognizes that scattered business events create weak decisions.

businessLogic: The problem must focus on cross-application event context, not generic productivity or generic monitoring.

architectureBoundary: Market-facing wording only.

acceptanceRule: The problem statement explains why isolated triggers and logs are not enough.

sourceReference: SignalWeaverLandingSite/Components/Pages/Home.razor, visibility-gap content.

threadStatus: Draft.

AIID-SW-UVP-003 Understanding Before Action

kind: ux-element

screenOrWorkflow: Market value proposition

actor: buyer or customer sponsor

intent: Explain the central value claim.

coreUseCase: Customer understands that SignalWeaver helps action become intentional.

businessLogic: The claim must state that evidence and understanding come before downstream action.

architectureBoundary: SignalWeaver owns evidence. Subscriber applications own action.

acceptanceRule: The value claim says action is downstream of understanding.

sourceReference: SignalWeaverLandingSite/Components/Pages/Home.razor, Act with Intent.

threadStatus: Draft.

AIID-SW-UVP-004 Controlled Publisher Rail

kind: integration

screenOrWorkflow: SignalWeaver publish flow

actor: SignalWeaver operator

intent: Identify the transport and authorization value that supports the market claim.

coreUseCase: An approved publisher emits a registered event through a controlled route.

businessLogic: Publish authority, registered event, route, delivery, and audit are part of the value proposition.

architectureBoundary: Source applications publish business facts. SignalWeaver validates and routes them.

distributedContracts: Existing SignalWeaver patterns build a CDE with a registered event and publish through ICloudEventManager.

acceptanceRule: Product wording includes controlled publisher authority without claiming payload ownership.

sourceReference: SignalWeaverLandingSite/Services/SignalWeaverPublisher.cs; SignalWeaver.SDK/README.md.

threadStatus: Draft.

AIID-SW-UVP-005 Signal Not Trigger

kind: business-rule

screenOrWorkflow: Product positioning

actor: buyer or application owner

intent: Explain why SignalWeaver is different from immediate trigger automation.

coreUseCase: Customer sees that events are interpreted through sequence, timing, and relationship.

businessLogic: Not every event demands action. Events create conditions for interpretation.

architectureBoundary: SignalWeaver preserves the event flow; subscribers decide action.

acceptanceRule: Market copy says an event becomes a signal because context indicates importance.

sourceReference: SignalWeaverLandingSite/Components/Pages/Home.razor, Patterns Emerge.

threadStatus: Draft.

AIID-SW-UVP-006 Multiple Listeners

kind: business-rule

screenOrWorkflow: Product positioning

actor: subscriber application owner

intent: Show how multiple subscribers can create value without corrupting the source record.

coreUseCase: Different listeners interpret the same event sequence from different business perspectives.

businessLogic: Subscriber interpretation is separate from the original event fact.

architectureBoundary: SignalWeaver owns delivery and evidence. Subscribers own interpretation.

acceptanceRule: The product claim allows different listeners without changing the source event.

sourceReference: SignalWeaverLandingSite/Components/Pages/Home.razor, listener copy.

threadStatus: Draft.

AIID-SW-UVP-007 Event Contract Vocabulary

kind: data-state

screenOrWorkflow: Event contract service

actor: SignalWeaver operator

intent: Explain the contract-level knowledge model behind market differentiation.

coreUseCase: SignalWeaver organizes event definitions, versions, domains, relationships, and expectations.

businessLogic: Contract vocabulary supports validation and interpretation, not payload execution.

architectureBoundary: Event contract service owns event vocabulary and relationships. Applications own payload meaning.

acceptanceRule: The claim stays at event contract level.

sourceReference: _Documentation/planning/20260510-signalweaver-evt-event-contract-service-plan.md.

threadStatus: Draft.

AIID-SW-UVP-008 Audit Evidence

kind: data-state

screenOrWorkflow: Event dashboard and audit trail

actor: customer technical sponsor

intent: Show how SignalWeaver provides proof, not just movement.

coreUseCase: Customer traces what reached SignalWeaver, where it was routed, and what follow-up was observed.

businessLogic: Audit evidence supports investigation and decision-making; it does not guarantee business success.

architectureBoundary: SignalWeaver owns transport and platform audit. Subscribers own domain execution records.

acceptanceRule: Market copy promises traceable evidence, not automatic resolution.

sourceReference: _Documentation/planning/20260509-event-dashboard-record-definition-plan.md.

threadStatus: Draft.

AIID-SW-UVP-009 Subscriber-Owned Action

kind: decision

screenOrWorkflow: Product boundary

actor: buyer, subscriber owner, or implementation sponsor

intent: Prevent the market claim from turning SignalWeaver into a workflow engine.

coreUseCase: Customer understands that subscriber systems own business decisions.

businessLogic: SignalWeaver must be positioned as event contract, route, delivery, audit, and authorization.

architectureBoundary: Subscriber applications own processing and payload interpretation.

acceptanceRule: Product copy includes a direct "SignalWeaver is not the customer's workflow engine" boundary.

sourceReference: Assumption SW-A-004; _Documentation/planning/20260510-signalweaver-evt-event-contract-service-plan.md.

threadStatus: Draft.

AIID-SW-UVP-010 Agentic Onboarding

kind: integration

screenOrWorkflow: Authorized implementation support

actor: authorized agent or external host operator

intent: Explain how SignalWeaver can support agentic and AI-assisted environments safely.

coreUseCase: Authorized agents help validate webhooks, register subscribers, check sync, and retrieve SDK configuration.

businessLogic: Agent support must be authorized and must not bypass publisher, subscriber, or event contract control.

architectureBoundary: MCP is an operational support surface, not the public product definition.

acceptanceRule: Product wording describes controlled agent participation, not unrestricted automation.

sourceReference: Eventryx.Mcp/Tools/SignalWeaverSubscriptionTools.cs.

threadStatus: Draft.

AIID-SW-UVP-011 Target Market

kind: ux-element

screenOrWorkflow: Market definition

actor: buyer or market reviewer

intent: Identify where SignalWeaver has strongest value.

coreUseCase: Buyer recognizes fit for multi-application, AI-assisted, partner, or agentic systems.

businessLogic: The target market should emphasize cross-boundary event visibility and controlled action.

architectureBoundary: Market-facing definition only.

acceptanceRule: The target market names AI-assisted and multi-application environments.

sourceReference: Local assumption SW-A-006.

threadStatus: Draft.

AIID-SW-UVP-012 Competitive Differentiation

kind: decision

screenOrWorkflow: Market differentiation

actor: buyer comparing alternatives

intent: Explain what SignalWeaver adds beyond adjacent categories.

coreUseCase: Customer compares SignalWeaver to logs, queues, service buses, iPaaS, and workflow engines.

businessLogic: Differentiation must say what SignalWeaver adds without misrepresenting the adjacent category.

architectureBoundary: Market-facing positioning only.

acceptanceRule: The differentiation table identifies at least four adjacent categories.

sourceReference: Assumption analysis Candidate Abstractions.

threadStatus: Draft.

Competitive Differentiation

Category	What It Does	What SignalWeaver Adds
Logs and observability	Shows technical traces and failures.	Business event contracts, route evidence, and subscriber context.
Queues and service buses	Moves messages reliably.	Market-visible event meaning, publisher authority, subscriber onboarding, and audit trail.
Event Grid	Delivers events at cloud scale.	Product-level contract, authorization, subscriber lifecycle, and business-event evidence.
iPaaS	Connects applications and transforms data.	Controlled event evidence without centralizing all business logic.
Workflow engines	Orchestrate tasks and decisions.	Understanding before action while leaving execution inside owning applications.
Support ticketing or CRM	Captures human follow-up.	System-level event truth before the human support process begins.

Acceptance Criteria

• The document is about SignalWeaver only.
• BackTheApp is mentioned only as marketing/advertising context, not product scope.
• The unique value proposition is explicit and market-facing.
• The AIID tokens map each market claim to a product boundary and acceptance rule.
• The specification does not create event names, publishers, subscribers, grants, or MCP operations.
• The product boundary is explicit: SignalWeaver owns event contract, route, delivery, audit, authorization, and evidence; subscriber applications own business logic and action.

Open Questions

• Should the market label be business-event intelligence rail, event intelligence rail, or another customer-facing phrase?
• Which target market should lead the first public copy: AI-assisted applications, multi-application operations, partner event flows, or evidence-backed automation?
• How much technical language should appear in the public marketing copy versus a technical appendix?

MDPolish is a Phoenix-built document polishing application that turns Markdown and structured source content into professional document outputs.

AlignIQ landing page with successful resume-to-job-description comparison workflow at /jobhelp.

BackTheApp is a Phoenix-built application platform for organizing software ideas into a public queue, connecting support to specific applications, and moving approved application work through an AI-assisted delivery lifecycle.

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.

File-Centric Change Sentinel Specification

Purpose

Create a proactive workstation application that tracks which current working directory is changing which files, why those files are changing, and whether the work is starting to create merge or coordination risk.

The application is intentionally file-centric. Git branches, worktrees, pull requests, and commits are metadata around the file change. They are not the primary human view.

Human Intent

A human should be able to answer these questions quickly:

• What CWD is changing files right now?
• Which files changed, and why?
• Which branch, PR, or intent owns each changed file?
• Is another local CWD, GitHub branch, or open PR changing the same file?
• Is a merge conflict starting before Git reports it at merge time?
• Is this change safe to continue, or should the human pause and review?

Product Name

Working name: Change Sentinel.

This is distinct from a branch visualizer. The product watches file changes, maps them to intent, and raises coordination alarms.

Core Principle

A branch is a transport mechanism. A file change intent is the human artifact.

The application should store and display:

• CWD
• repo
• file
• change status
• owning intent
• actor
• branch
• GitHub branch
• PR
• conflict risk
• deployment relevance

Scope

In Scope

• Watch one or more local repo CWDs.
• Discover Git worktrees, but treat each worktree as a CWD rather than as the primary product model.
• Detect changed files after each filesystem or Git status change.
• Track each changed file back to CWD, branch, actor, and intent.
• Compare local changed files against:
  • other local CWDs for the same repo,
  • GitHub/development,
  • GitHub/master or GitHub/main,
  • open PR head branches.
• Raise alarms when overlap or likely merge risk appears.
• Show a file-centric dashboard.
• Provide an agent-readable status endpoint or file.
• Preserve an audit trail of why a warning was raised.
• Optionally publish coordination issues to GitHub for cross-workstation awareness.

Out of Scope for MVP

• Replacing Git, GitHub, or PRs.
• Blocking file writes.
• Full semantic merge automation.
• Cloud service coordination across many users.
• Global policy enforcement.

Vocabulary

Term	Meaning
CWD	A physical working directory on the workstation. This may be a primary checkout or Git worktree.
File change	A changed, added, deleted, renamed, or untracked file in a CWD.
Intent	The reason for the change, such as a user request, issue, PR, deployment fix, or agent session.
Actor	Human, AI agent, IDE, script, build tool, or deployment tool performing the change.
Root branch	The repo production/source-of-truth branch advertised by GitHub, usually master or main.
GitHub/development	Human label for origin/development.
local/development	Human label for the local development branch.
Alarm	A warning raised before a merge conflict or coordination problem becomes expensive.
Workstream	An active unit of work in a CWD, usually tied to an intent, branch, issue, PR, or agent session.
Coordination artifact	A GitHub Issue or local record used to communicate active work and overlap.

Architecture

flowchart LR Human["Human"] --> CWD1["CWD / Worktree"] Agent["AI Agent"] --> CWD2["CWD / Worktree"] Tool["IDE / Script"] --> CWD3["CWD / Worktree"] CWD1 --> Sentinel["Change Sentinel Local"] CWD2 --> Sentinel CWD3 --> Sentinel Git["Git status / diff / branch metadata"] --> Sentinel GH["GitHub PRs / branches / optional issues"] --> Sentinel Roslyn["Roslyn / Razor / config parsers"] --> Sentinel Store["Local Sentinel Store"] <--> Sentinel Sentinel --> Dashboard["File-centric dashboard"] Sentinel --> Status["Agent-readable status"] Sentinel --> Alerts["Local alarms"] Sentinel <--> Issues["Optional GitHub coordination issues"]

Local Responsibilities

Change Sentinel Local runs as the signed-in workstation user. It should use the same Git and GitHub credentials the user already has.

Responsibilities:

• Discover local Git repositories and worktrees.
• Determine repo identity, CWD, branch, remote alignment, and changed files.
• Associate active work with issue, branch, PR, actor, and intent where available.
• Poll or watch filesystem and Git state.
• Analyze changed C# and Razor files with Roslyn where practical.
• Detect overlap across local CWDs.
• Poll GitHub PRs and branches for same-file and stale-branch risk.
• Surface warnings locally to the human and to agent-capable tools.
• Optionally create or update GitHub coordination issues using the local user's authorization.

MVP

Views

CWD View

Shows each monitored CWD:

CWD: C:\Users\Richard\source\repos\PhxBiz\ArticleMngrSLN
Repo: codeputer/ArticleMngrSLN
Branch: local/development
GitHub alignment: local/development == GitHub/development
Changed files: none
Alarms: none

File View

Shows all changed files grouped by file path, not branch:

File: deploy-temp/deploy-contenttraker-environment.ps1
Changed by:
  - CWD: C:\Users\Richard\source\repos\PhxBiz\ArticleMngrSLN
    Branch: codex/deploy-consistency-contract
    Intent: Enforce consistent Azure deployment
    PR: #160
Risk:
  - No local overlap
  - No open PR overlap
  - Production-relevant file

Alarm View

Shows actionable warnings:

Severity: blocker
File: ArticleMngrUserWeb/Components/Pages/SearchDiagnostics.razor
Reason: Two active branches changed overlapping hunks.
Actors:
  - CWD: ArticleMngrSLN
    Branch: local/development
    Intent: file_search diagnostics
  - GitHub branch: codex/use-vector-store-file-search
    PR: #158
Recommendation: Close stale PR or rebase before continuing.

Detection Model

Level 1: Dirty File

Signal:

• git status --porcelain reports a changed file.
• filesystem watcher reports a write and Git status confirms it.

Alarm:

• none by default.

Use:

• Updates CWD and file views.

Level 2: Local Same-File Overlap

Signal:

• Two monitored CWDs for the same repo have changes to the same repo-relative file.

Alarm:

• warning.

Use:

• Human should check whether the workstreams are actually independent.

Level 3: GitHub Branch Same-File Overlap

Signal:

• A local changed file is also changed by an open PR branch.
• A local changed file differs between GitHub/development and GitHub/master.

Alarm:

• warning for same file.
• blocker if the open PR is stale, conflicting, or targets the same base branch.

Level 4: Diff Hunk Overlap

Signal:

• Local diff hunks overlap or are adjacent to hunks in another CWD, branch, or PR.

Alarm:

• warning or blocker depending on proximity and file type.

Level 5: Semantic Boundary Overlap

Signal:

• C# changes touch the same class, method, property, or constructor.
• Razor changes touch the same component section, handler, parameter, or injected service.
• JSON/config changes touch the same key path.

Alarm:

• blocker when two active intents touch the same semantic boundary.

Conflict Risk Rules

The application should evaluate after each confirmed change.

Rule	Severity	Example
Same file changed in two local CWDs	warning	Two worktrees edit Program.cs.
Same file changed locally and in open PR	warning	Local edit overlaps PR #158 file list.
Same hunk changed by two workstreams	blocker	Both edit the same method body.
Local branch is behind GitHub/development and edits files changed upstream	blocker	Local stale branch edits SearchDiagnostics.razor.
Production deploy file changed outside root branch	blocker	Deploy script changed on feature branch and production deploy requested.
Open PR branch would delete files added by current GitHub/development	blocker	Stale PR diff removes current files.
File has uncommitted changes and deployment requested	blocker	Dirty worktree before deploy.

Data Model

Repository

{
  "repoId": "codeputer/ArticleMngrSLN",
  "rootPath": "C:/Users/Richard/source/repos/PhxBiz/ArticleMngrSLN",
  "rootBranchName": "master",
  "developmentBranchName": "development",
  "remoteName": "origin"
}

CWD Snapshot

{
  "cwdId": "articlemngr-main",
  "repoId": "codeputer/ArticleMngrSLN",
  "path": "C:/Users/Richard/source/repos/PhxBiz/ArticleMngrSLN",
  "branch": "development",
  "headCommit": "f86426e50d684f32ed5be37d182428a8c393ec1f",
  "githubDevelopmentCommit": "f86426e50d684f32ed5be37d182428a8c393ec1f",
  "githubRootCommit": "757634b...",
  "isClean": true,
  "capturedUtc": "2026-06-02T12:30:00Z"
}

File Change

{
  "repoId": "codeputer/ArticleMngrSLN",
  "cwdId": "articlemngr-main",
  "path": "deploy-temp/deploy-contenttraker-environment.ps1",
  "status": "modified",
  "intentId": "intent-deploy-consistency",
  "actor": {
    "type": "agent",
    "name": "codex"
  },
  "branch": "codex/deploy-consistency-contract",
  "baseBranch": "development",
  "prNumber": 160,
  "firstSeenUtc": "2026-06-02T12:10:00Z",
  "lastSeenUtc": "2026-06-02T12:20:00Z"
}

Alarm

{
  "alarmId": "alarm-20260602-searchdiagnostics-pr158",
  "severity": "blocker",
  "repoId": "codeputer/ArticleMngrSLN",
  "file": "ArticleMngrUserWeb/Components/Pages/SearchDiagnostics.razor",
  "reason": "Open PR branch changes the same file and is stale against GitHub/development.",
  "evidence": [
    "PR #158 mergeable=CONFLICTING",
    "GitHub/development contains PR #159 and PR #160",
    "Diff from GitHub/development to PR #158 would delete current diagnostics changes"
  ],
  "recommendation": "Close PR #158 and delete its branch.",
  "status": "active",
  "createdUtc": "2026-06-02T12:25:00Z"
}

Event Sources

Required

• git status --porcelain=v1
• git diff --name-status
• git diff --unified=0
• git branch --show-current
• git rev-parse HEAD
• git symbolic-ref --short refs/remotes/origin/HEAD
• git worktree list --porcelain
• GitHub CLI or GitHub API for PR file lists and mergeability.

Optional

• filesystem watcher for faster detection.
• Roslyn for C# semantic boundaries.
• Razor parser for component boundaries.
• JSON parser for appsettings and configuration files.
• local agent session metadata.

Proactive Check Loop

flowchart TD Watch["Filesystem or polling detects change"] --> Snapshot["Capture CWD Git snapshot"] Snapshot --> Files["Resolve changed files"] Files --> LocalCompare["Compare against other local CWDs"] Files --> RemoteCompare["Compare against GitHub branches and PRs"] Files --> HunkCompare["Compare diff hunks"] Files --> SemanticCompare["Compare semantic boundaries"] LocalCompare --> Risk["Score conflict risk"] RemoteCompare --> Risk HunkCompare --> Risk SemanticCompare --> Risk Risk --> Alarm{"Alarm?"} Alarm -->|No| Dashboard["Update dashboard"] Alarm -->|Yes| Notify["Write alarm, notify human and agents"]

Agent Integration

Agents should be able to query a local status artifact before editing:

.change-sentinel/status.json

Minimum agent-readable fields:

• current CWD identity,
• clean/dirty state,
• changed files,
• active alarms,
• files that should not be touched without human approval,
• current branch and GitHub alignment.

Agents should also write intent metadata when beginning work:

.change-sentinel/intents/{timestamp}-{slug}.json

Example:

{
  "intentId": "intent-deploy-consistency",
  "actor": {
    "type": "agent",
    "name": "codex"
  },
  "humanRequest": "tighten deployment consistency",
  "cwd": "C:/Users/Richard/source/repos/PhxBiz/ArticleMngrSLN",
  "expectedFiles": [
    "deploy-temp/deploy-contenttraker-environment.ps1",
    "_Documentation/ContentTraker-Deployment-Consistency-Contract.md"
  ],
  "startedUtc": "2026-06-02T12:10:00Z"
}

MVP

Implementation Plan

1. Build a CLI scanner that emits .change-sentinel/status.json.
2. Track all Git CWDs under C:/Users/Richard/source/repos.
3. Add GitHub PR file-list comparison.
4. Add same-file and stale-branch alarms.
5. Add diff-hunk overlap alarms.
6. Add a small local dashboard.
7. Add agent preflight conventions.
8. Add Roslyn/Razor semantic alarms after the file and hunk model is stable.

Optional GitHub Coordination

GitHub Issues can be used as a v1 cross-workstation coordination ledger when more than one workstation or actor is working in the same repository.

The application should not send raw high-frequency telemetry to GitHub. GitHub Issues should contain meaningful coordination events:

• active workstream registration,
• overlap warning,
• overlap conflict,
• blocker requiring review,
• acknowledgement,
• resolution.

Labels

Each participating repository may define these labels:

Label	Purpose
sentinel:workstream	Tracks an active workstream registered by Change Sentinel.
sentinel:overlap-warning	Indicates same-file overlap or lower-confidence overlap.
sentinel:overlap-conflict	Indicates hunk, symbol, or responsibility-boundary overlap.
sentinel:blocker	Indicates work should slow down pending review.
sentinel:acknowledged	Indicates a human or responsible actor has reviewed the overlap.
sentinel:resolved	Indicates the overlap no longer requires attention.

Workstream Issue Shape

Title:

[Change Sentinel] Active workstream: codex/deploy-consistency-contract

Labels:

sentinel:workstream

Body:

repo: codeputer/ArticleMngrSLN
cwd: C:/Users/Richard/source/repos/PhxBiz/ArticleMngrSLN
branch: codex/deploy-consistency-contract
actor:
  type: agent
  name: codex
intent:
  source: human-request
  title: tighten deployment consistency
status: active
heartbeatUtc: 2026-06-02T12:00:00Z
changedFiles:
  - deploy-temp/deploy-contenttraker-environment.ps1
  - _Documentation/ContentTraker-Deployment-Consistency-Contract.md

Overlap Issue Shape

Title:

[Change Sentinel] Overlap detected: SearchDiagnostics.razor

Labels:

sentinel:overlap-conflict
sentinel:blocker

Body:

repo: codeputer/ArticleMngrSLN
file: ArticleMngrUserWeb/Components/Pages/SearchDiagnostics.razor
severity: blocker
reason: Open PR branch changes the same file and is stale against GitHub/development.
workstreams:
  - branch: codex/use-vector-store-file-search
    pr: 158
    status: stale
  - branch: development
    pr: 159
    status: merged
recommendation: Close PR #158 and delete the stale branch.

Runtime Model

V1 should be a workstation-local service. On Windows, this can be installed as a Windows service or started as a user-level background process.

The service should run as the signed-in user. This preserves the existing Git and GitHub authorization model. If the user cannot create an issue in a repository, Change Sentinel should not be able to create one either.

Implementation Phases

Phase 1: File-Level Local Sentinel

• Discover Git CWDs and worktrees.
• Poll git status, git diff --name-status, and branch metadata.
• Store local CWD and file-change state.
• Detect same-file overlap across local CWDs.
• Show local warnings.

Phase 2: GitHub PR and Branch Risk

• Read open PR file lists and mergeability.
• Compare local changed files with open PRs.
• Detect stale PR branches that conflict with GitHub/development.
• Detect branches with no open PR and no clear active intent.

Phase 3: Optional GitHub Issue Coordination

• Configure labels.
• Create/update active workstream issues.
• Create/update overlap issues.
• Throttle updates to avoid issue noise.

Phase 4: Semantic Detection

• Parse changed .cs and .razor files.
• Identify touched classes, methods, properties, and components.
• Upgrade overlap severity when the same symbol is touched.

Phase 5: Agent and IDE Integration

• Expose a local endpoint for agents to check before editing.
• Add desktop or tray notifications.
• Add Visual Studio or VS Code status surfaces if useful.

MVP

Acceptance Criteria

• Shows every monitored CWD and branch.
• Shows changed files grouped by file path.
• Identifies whether local/development matches GitHub/development.
• Identifies whether local/master matches GitHub/master.
• Detects local file overlap across CWDs.
• Detects overlap with open PR file lists.
• Detects stale PR branches that would remove or overwrite current GitHub/development changes.
• Emits an alarm before a production deploy from a dirty or non-root source.
• Writes machine-readable status for AI agents.
• Can optionally publish meaningful coordination issues without broad GitHub credentials.

First ContentTraker Scenario

The scenario that just occurred should be a test case:

1. Feature work starts on codex/use-vector-store-file-search.
2. Later work is merged through PR #159 and PR #160.
3. PR #158 remains open and becomes stale/conflicting.
4. Change Sentinel detects that PR #158 is no longer the path forward because its diff conflicts with GitHub/development.
5. Alarm recommends closing PR #158 and deleting the branch.

Expected result:

Severity: blocker
Reason: Open PR branch is stale and conflicting with GitHub/development.
Recommendation: Close PR #158 and delete codex/use-vector-store-file-search.

TrustSender

You don't trust AI to answer your email.

You trust AI to decide whether you should read it in the first place.

Every morning starts the same way.

You open your inbox.

327 unread emails.

You already know what's coming.

Delete.

Archive.

Ignore.

Repeat.

Somewhere in those hundreds of messages is one that matters.

A customer.

A recruiter.

A family member.

An invoice.

An opportunity.

You know it's there.

You just don't know where.

The hardest part of email isn't replying.

It's deciding what deserves your attention.

The First Decision

Today's email systems help you after you've opened the message.

TrustSender helps before you ever read it.

Because the first decision is the one that costs the most time.

Should I read this?

Should I ignore it?

Is this important?

Is this another sales pitch?

Did I miss something yesterday?

Hundreds of tiny decisions become hours every week.

Your AI Bodyguard

Every important person has someone they trust to manage access.

A bodyguard doesn't decide who is important.

A bodyguard enforces the wishes of the person they're protecting.

Known people are welcomed.

Expected visitors are welcomed.

Unknown visitors identify themselves.

Everyone else waits.

TrustSender brings that same idea to your inbox.

It doesn't replace your judgment.

It represents it.

It learns who you trust.

It verifies people it doesn't know.

It enforces your rules before you have to read another email.

Trusted Delegation

Everyone is talking about AI agents.

Most AI agents help you create content, write code, or answer questions.

TrustSender has a different job.

It makes the first decision on your behalf.

Not because AI knows better than you.

Because you've taught it how you decide.

Every decision reflects your relationships.

Your priorities.

Your policies.

Your trust.

A Better Inbox

Imagine opening your inbox and knowing someone has already done the difficult work.

The people you know are already waiting.

The messages you care about are easy to find.

Unknown senders have been verified or are waiting for approval.

The noise has already been dealt with.

You don't spend your morning deciding what to ignore.

You spend it responding to the people who matter.

A Different Question

Traditional spam filters ask:

"Is this spam?"

TrustSender asks:

"Should this email reach you before you've decided it deserves your attention?"

That one question changes everything.

The Promise

TrustSender doesn't read your email because it reads faster than you.

It reads your email because you trust it to make the first decision on your behalf.

When you finally open your inbox, the hard work is already done.

That's what trusted delegation looks like.

That's TrustSender.