Description

Methods

Detailed Step-by-Step Workflow

The architecture changes business-discovery communication from a possession-based model into an authority-based model. A telephone number, messaging reference, marketplace thread, relay address, or other communication handle is not treated as continuing permission to reach the user. Communication becomes effective only after the required authorization state is verified at the communication-finality boundary.

Step 1 — User Creates a Business-Discovery Query

The process begins when a user performs a map search, local-service search, marketplace inquiry, quotation request, booking inquiry, or similar service-discovery action.

For example, the user may ask:

“Find plumbers near me.”

The request can originate directly from the user or through an AI assistant acting on the user's instruction. The AI system may identify candidate businesses, retrieve listings, rank them, and prepare a proposed communication. However, finding a business or generating a proposed message does not itself authorize communication.

Step 2 — A Query-Scoped Communication Context Is Created

The platform establishes a communication context associated with the specific inquiry.

That context can bind parameters such as:

• the user or privacy-preserved user identity;

• the particular query;

• the selected business or eligible business group;

• business category;

• permitted purpose;

• permitted communication channel;

• communication direction;

• permitted communication effect;

• AI-agent identity where applicable;

• expiration or freshness;

• quota;

• revocation state;

• nonce state; and

• the enforcement point expected to verify the authority.

The key principle is that authorization is associated with the specific transaction or inquiry rather than with permanent user reachability. The disclosed architecture explicitly supports binding authorization to these types of contextual attributes.

Step 3 — A Communication Reference May Be Exposed Without Exposing Permanent Reachability

The business may receive a communication opportunity, query-scoped reference, relay identifier, marketplace lead reference, or another routing mechanism.

Importantly, the visible reference is not itself the authority.

The business therefore does not gain unrestricted reachability merely because it:

• sees the reference;

• records it;

• copies it;

• stores it;

• forwards it;

• previously communicated through it; or

• later obtains it through another database.

The underlying architecture treats communication reachability as a bounded capability rather than something obtained simply by possession of a contact reference.

Step 4 — The First Communication Exists Initially as a Candidate Communication Act

Suppose the user or an AI assistant wants to contact a business.

The proposed call, message, WebRTC connection, callback request, or other communication is first treated as a candidate communication act.

It is not immediately allowed to produce an external communication consequence.

The request remains in a non-effective state while authorization is evaluated. For AI-agent communication, the specification expressly describes the generated request as a candidate communication act or non-effective communication request.

Conceptually:

Query → Candidate Communication → Verification → Effectuation

rather than:

Query → Communication Automatically Happens

Step 5 — The Request Reaches the Protected Enforcement Point

Before communication becomes effective, the request reaches an enforcement point.

Depending upon implementation, this may be located at a:

• communication relay;

• platform gateway;

• cloud communication gateway;

• SIP proxy;

• session border controller;

• WebRTC signaling service;

• TURN relay;

• messaging gateway;

• RCS/SMS gateway;

• email relay;

• push-notification gateway;

• operating-system broker;

• device-side communication broker;

• secure enclave;

• trusted execution environment; or

• HSM-backed protected verifier.

The specification permits device-side, cloud-side, and hybrid implementations.

Step 6 — The Enforcement Point Verifies the Actual Authority

The enforcement point does not ask merely:

“Does this business possess the handle?”

Instead, it asks whether the particular communication being requested is authorized.

For example, verification may determine:

• Is this the authorized business?

• Is this still the same user inquiry?

• Is the requested purpose permitted?

• Is this communication channel permitted?

• Is the direction of contact permitted?

• Is the authorization still fresh?

• Has the authorization expired?

• Has the user revoked it?

• Has the communication quota been exhausted?

• Has the nonce already been consumed?

• Is the AI agent operating within its permitted scope?

• Is the communication being presented to the correct enforcement point?

The architecture therefore validates the authority associated with the communication consequence, not simply an identity or routing address.

Step 7 — The Communication Resource Remains Withheld During Verification

While verification is occurring, the actual consequence-bearing resource remains unavailable.

Depending on the communication type, this may mean that the system has not yet:

• allocated the call bridge;

• created the SIP dialog;

• opened the RTP media path;

• established the WebRTC session;

• allocated the TURN resource;

• created the message thread;

• delivered the notification;

• opened an email relay;

• established the callback path; or

• awakened or rendered the communication on the user's device.

The zero-trust relay embodiment expressly withholds these resources until authorization has been verified.

Step 8 — Valid Authorization Causes Communication Effectuation

If verification succeeds, the enforcement point may release the required communication-bearing resource.

For example:

Valid authority

→ allocate call bridge
→ connect permitted parties
→ permit specified communication
→ consume or update protected authorization state.

Thus, the communication is not permitted because a phone number or handle exists.

It becomes effective because the system has verified authority for that particular effect.

Step 9 — Invalid Authorization Fails Closed

If verification fails, the request remains non-effective.

Examples include:

• expired authorization;

• revoked authorization;

• business-identity mismatch;

• wrong query;

• wrong purpose;

• wrong communication channel;

• quota exhaustion;

• nonce replay;

• stale authorization;

• missing enforcement-point binding;

• unverifiable signature or authentication state;

• AI-agent identity mismatch; or

• failure of a required protected-state operation.

Under the disclosed fail-closed model, the communication resource is not redirected through an ordinary unverified fallback path merely because the authorization infrastructure is unavailable.

Step 10 — Preview Communication Can Be Separated From Continuing Reachability

One important feature is the separation between a temporary preview interaction and permission for continued communication.

For example, a plumber may receive permission for:

• one short preview call;

• a limited message exchange;

• a short WebRTC session; or

• another bounded interaction.

The specification describes preview communication that may be limited by duration, message count, replies, or another defined allowance.

The business therefore gets an opportunity to interact with the prospective customer without automatically obtaining permanent contact authority.

Step 11 — Preview Contact Does Not Automatically Become Future Contact Authority

After the preview, the business may want to continue speaking with the user.

But the earlier interaction does not automatically grant that right.

The business may submit a request for continued communication. Depending on implementation, this may involve:

• business selection;

• user approval;

• callback consent;

• quote acceptance;

• booking confirmation;

• payment;

• platform eligibility;

• subscription entitlement; or

• another defined qualification condition.

Crucially, the business's request or payment does not itself create reachability. It becomes one predicate considered when deciding whether a new future authorization state should be issued.

Step 12 — A Separate Future Communication Authorization Is Issued

If all required conditions are met, the architecture may issue a separate future communication authorization.

That authorization can itself remain tightly bounded.

For example, it may permit:

• two additional calls;

• five messages;

• communication for 24 hours;

• communication only with the same business;

• communication only about the original plumbing inquiry;

• communication only through chat;

• communication only from the authorized business account;

• communication only from a specified AI agent or call center; or

• communication until the user revokes it.

The specification expressly describes future authority bounded by message/call counts, time windows, identity, purpose, channel, location, lead state, booking state, payment state, revocation, and user-controlled termination.

Step 13 — Every Later Attempt Is Independently Checked

Obtaining future authorization does not mean that the business receives an unrestricted permanent telephone number.

For every subsequent communication attempt, the enforcement point can again verify whether that specific attempt falls within the continuing authorization.

Therefore:

authorization for Call 1 ≠ permanent authority for Call 2, Call 3, Call 100.

If the authorization has expired, been revoked, exceeded quota, changed purpose, or otherwise fallen outside scope, the new communication remains non-effective.

Step 14 — Cross-Purpose Contact Is Prevented

Consider this example.

The user searches:

“plumbers near me.”

A plumbing business receives bounded communication authority for that plumbing inquiry.

Later, the same business, an affiliate, reseller, call center, or marketing partner attempts to use the same relationship to offer:

• loans;

• insurance;

• real estate;

• hotel promotions;

• unrelated marketing; or

• another service.

The architecture compares the proposed new communication against the original authorized purpose and context.

Because the new communication is outside the authorized plumbing inquiry, the request fails scope verification and remains non-effective. The disclosure specifically describes this type of identity-pivot and purpose-pivot prevention.

Step 15 — Leakage of the Handle Does Not Automatically Create Reachability

Suppose the business database is compromised and the communication reference is leaked.

In a conventional possession-based architecture, an attacker may obtain something directly useful for contacting the user.

Under this architecture, the leaked reference does not independently satisfy the required authorization predicates.

The attacker still lacks valid authority associated with the correct:

• business;

• query;

• purpose;

• state;

• quota;

• nonce;

• authorization epoch;

• channel; and

• enforcement boundary.

The design therefore separates leakage of a routing reference from leakage of communication authority.

Step 16 — AI Agents Are Subject to the Same Finality Boundary

The architecture becomes particularly important in AI-native telecommunications.

For example, an AI assistant may be instructed:

“Find three plumbers near me and ask each one whether they can come tomorrow.”

The AI may:

1. identify candidate businesses;

2. prepare questions;

3. select communication tools; and

4. request that messages or calls be initiated.

But the AI's capability to use a communication tool is not itself treated as authorization to create every possible communication consequence.

The enforcement point can permit the AI only to perform the narrowly authorized activity—for example, requesting availability—while preventing it from creating a persistent thread, disclosing permanent contact details, booking an appointment, sending payment information, or granting future callback authority without a separately authorized state.

Step 17 — Communication Authority Can Continue Across Applications Without Becoming a Bearer Credential

The same authorization principle can operate across different applications or services.

For example:

Map search → AI assistant → booking service → payment application → messaging service

The communication authority can be referenced across that workflow without requiring every application to receive the user's permanent telephone number or email address.

A later application does not gain communication permission merely because an earlier application performed a search, booking, payment, message, or handle exposure. The receiving enforcement point independently verifies the relevant authorization before allowing the communication effect.

Simplified End-to-End Flow

The architecture can therefore be summarized as:

1. User creates an inquiry

↓

2. Platform/AI discovers candidate businesses

↓

3. Query-scoped communication context is established

↓

4. Business receives a routing reference or communication opportunity

↓

5. User, business, or AI proposes a communication

↓

6. Communication remains non-effective

↓

7. Protected enforcement point receives the request

↓

8. Identity + query + purpose + channel + effect + freshness + quota + nonce + revocation + other predicates are verified

↓

If verification succeeds:

9A. Communication resource is released

↓

10A. Call/message/session becomes effective

↓

11A. Required state/quota/nonce is updated

↓

12A. Any later communication must again satisfy the applicable authorization

If verification fails:

9B. Communication remains non-effective

↓

10B. No call bridge, message delivery, WebRTC session, notification, callback route, or equivalent consequence is created

↓

11B. Request fails closed

Difference From Conventional Communication Systems

Core Distinction

The fundamental difference can be expressed in one sentence:

Conventional systems protect the contact identifier; this architecture protects the authority to create contact.

A conventional masked number asks:

“How can we hide the user's real number?”

This architecture asks a more fundamental question:

“Even if the communication reference becomes known, why should possession of it give anyone continuing authority to reach the user?”

The resulting design therefore shifts anti-spam, anti-harassment and privacy protection from identity concealment and post-event blocking toward pre-effectuation, purpose-bounded, query-bounded and revocable communication authority.

Notes