Instances

Instances are provisioned from a Meeting Type and tracked on the instances page. Edits to a Meeting Type will only be reflected in new instances which are created after the

edits are published. A Meeting Type's purpose is templated provisioning of unique copes of itself. These copies are known as instances.

Minimum requirements to create an instance are are user, contact, and a designated meeting type.

Instances can be created automatically through the use of channels or manually from the instances page. If created automatically an instance needs to satisfy the 3 requirements listed above. A user, contact, and meeting type.

The Relationship Between

Meeting Types & Instances

Meeeting Type Machine-1

An Instance can exist in 3 states. These states are typically referred to as an instances "lifecycle". These 3 states are Initialization, Scheduling, and Final. Keep in mind, many statuses exist within a given state. So status and state have a hierarchical relationship.

The Instance Lifecycle

3 States of an Instance

Screen Shot 2020-07-15 at 10.24.50 PM

Initialization: During this state instances are created using the 3 required ingredients to manifest their existence. A user, a contact, and & meeting type. These 3 ingredients can be manually or automatically.

Scheduling: Once a fully initialized instance activated in enters the Scheduling state. There are two "sub-states" with the Scheduling State. "Active" & "Manual". Active Scheduling is the process which automation and A.I. are at work to automate & monetize a users calendar. If there is an out of bounds occurrence Active scheduling is switched to manual scheduling, and the user is notified to take control

Final: An instance that has reached it's outcome is known to be in a final state. A user, contact, or standardized process can be the cause of an instance entering into the final state. Instances in the "Final" state have two sub states. Impending, & Retired, if an instance is impending it has a start time in the future. This instance will not retire until it moves into the past.

Instance Status Diagram

V2.2 Status Description Egress & Ingress

Status	Description	Ingress Statuses	Egress Statuses
Initializing	Configuration of required elements needed for activation underway.	None	Initialized
Initialization Error	Attempt to assemble element of instance failed.	Initializing	Initialized
Initialized	Instance elements assembled completely, ready for activation.	Initializing Initialization Error	*Proposal Pending* *Queued (Beta)*
Queued (Beta)	An instance is considered Queued when a proposal attempt is scheduled for a time in the future. This can occur when the AI detects a recipients desire to reschedule at a future date. Example: an automated Out of Office style response from a recipient which gives an in-office date. A second cause of this status can result from an instance respecting a Proposal Attempt Window. Example: Behavior for Meeting Type A has defined a Proposal Attempt Window from from 8am to 5pm. A prior proposal for an instance of Type A is recycled at 11pm, therefore will be queued with the next proposal attempt occurring after 8am. Note, the instance start time can be either known or unknown.	Proposal Pending Initialized	Proposal Pending
Proposal Pending	Instances are considered pending when a specific proposal is available for a recipient to engage.	Initialized *Queued*	Accepted Declined Requires User Intervention User Intervened A.I. Negotiating Queued
A.I. Negotiating	A recipient replies to a proposal with an alternate proposal and the Kronologic AI is confident in the recipients proposal intent.	Proposal Pending	Accepted Declined
Scheduling Paused (Beta)	A Paused instance remains in it’s pre-paused state and limits instance behavior. When an instance is un-paused behavior resumes with the instance respecting any environmental changes that occurred during a pause.
Requires User Intervention	A recipient replies to a proposal attempt & AI intent recognition confidence is less than defined threshold.	Proposal Pending A.I. Negotiating	Proposal Pending Accepted Declined Engaged no Intent
User Intervened	User has interacted with recipient response. This can from a needed required intervention, or from a user intervention within the A.I. Negotiation Delay Period.	Requires User Intervention: User replies back to recipient or moves invite. Proposal Pending: Recipient responds and user opens email before Kronologic attempts to negotiate. Interaction with the hidden calendar does not constitute user intervened. Users should never interact with the hidden calendar. A.I. Negotiating: User opens email thread or moves invite anytime during the negotiating process.	Accepted: Recipient ultimately accepts a manually negotiated invite. Declined: Recipient ultimately declines a manually negotiated proposition. Engaged no Intent: No intent is detected by Kronologic, recipient does not accept or decline a manually managed proposal.
Accepted	Instance proposal is accepted by recipient either though the a calendar invite or A.I. detected intent.	Proposal Pending A.I. Negotiating Requires User Intervention User Intervened	None
Declined	A declined instance is the result of	Proposal Pending A.I. Negotiating Requires User Intervention User Intervened	None
No Response.	An instance completes it’s defined behavior with no engagement from recipient	Proposal Pending	None
Engaged no Intent	Response detected from the recipient, original proposed meeting is in the past, no intent ever detected. Prior possible states are Requires User Intervention, and User Intervened.	Requires User Intervention User Intervened	None
Canceled	An instance is canceled by a user manually from the interface, from an intercept channel, or the system detects another active thread in the user’s inbox prior to proposal attempt.		None

Routing

Routing is how an instance is assigned to a user. Instances must be routed during the Initialization state.

Routing can be done either manually, or automatically. Automatic routing can occur at two movements in an instances lifecycle.

1) When an instance is first initialized.

2) When an instance is activated.

The timing of automatic routing is defined the Meeting Type, as well as several types of automatic routing logic.

Series vs. Parallel

Two instances associated with the same contact of the same meeting type can not be active at the same time. Another way to say this, is two instances of the same type can not be active in parallel for a given contact. However a contact can have two instances of different types active in parallel. Additionally, a contact can have two instances of the same type as long as they are active at different times. Or in series.

Attempts

Email attempts to set a meeting are defined in the Meeting Type. Each attempt is made by an algorithm designed to optimize for instance throughput and maximizing accept probability. A good estimate is that an instance with 3 attempts will take about 1.5 weeks to fully process if there is no response. Typically a consecutive attempt is sent within hours of the previous unaccepted proposal.