Skip to content

Ibby Handshake

System-enforced mutual commitment to a real first conversation

Summary

Ibby Handshake converts intent into action by enforcing a timed, verified commitment to a first conversation—using capacity gating, SLAs, and progressive consequences on both sides

Purpose

The Ibby Handshake is the mechanism that turns "interest" into a reliable first conversation. It exists to eliminate the most corrosive failure modes in modern hiring:

  • ghosted intent - expressing interest and then vanishing waits cycles that both parties could spend pursuing real opportunity

  • long wait periods - even if there's interest, delays in initial contact can cause undue burden on the candidate and other companies they may be speaking with. Everyone benefits from swift processing.

  • Spammy interest from non-serious applicants

It is not a promise to hire, continue, or negotiate. It is a promise to complete exactly one step:

A real first conversation (e.g., 20–30 minutes) within a defined window, once both parties affirm.

This section defines the Handshake as an enforceable workflow with timers, verification, reversible mistakes, and progressive consequences on both sides.

Definitions

Parties

  • Company: employer / hiring team using Ibby.
  • Candidate: person represented by a Candidate Agent / profile.

Core Objects

  • Qualified Match Brief: structured representation pairing a candidate and a role/company.
  • Handshake: a time-bound, system-enforced agreement to meet/interview.
  • Active Handshake: a handshake where both parties have affirmed interest, interview actively being scheduled.

What counts as "completed"

A handshake is completed when:

High-level Workflow (Narrative)

  1. Ibby produces a Qualified Match Brief
  2. Company reviews and, if genuinely interested, clicks Affirm Interest (pre-commit).
  3. Candidate reviews the company/role brief and, if interested, clicks Affirm Interest.
  4. Once both affirm, the handshake becomes active and timers start.
  5. Company must propose times (or accept candidate times) within the Scheduling SLA.
  6. The conversation occurs within the Conversation SLA.
  7. Both sides confirm completion. If disagreement occurs, Ibby resolves via a dispute flow.
  8. Compliance affects each party's future access, priority, cost, and rate of matches.

State Machine (System Model)

States

  1. Draft Match

    • Match brief exists, not yet affirmed by either party.

  2. Company Pre-Commit

    • Company clicks "Affirm Interest."
    • Candidate is not yet de-anonymized (if applicable).
    • System displays commitment preview and binds company intent if candidate reciprocates.

  3. Mutual Affirmed (Binding)

    • Candidate clicks "Affirm Interest."
    • Handshake becomes binding.
    • Company receives de-anonymized contact details for candidate
    • Timers start:
    • Scheduling SLA timer
    • Conversation SLA timer

  4. Scheduling In Progress

    • Parties propose/accept time slots.
    • System records proposals and response timestamps.

  5. Scheduled

    • A time is agreed upon.

  6. Completed

    • Conversation occurred and verified.

  7. Breached / Closed

    • Conversation did not occur in time, or scheduling SLA breached.
    • Failure reason recorded and enforcement applied.

  8. Dispute

    • Parties disagree on whether the conversation occurred or who failed to respond.

Operational timing targets

See the SLA for explicit timing commitments. If this section conflicts with the SLA, the SLA controls.

"Mutual affirmation" occurs when both parties affirm the handshake -- company, then candidate -- creating an Active Handshake.

Scheduling (Company-side)

  • Company must propose viable times within X hours of mutual affirmation.

  • "Propose times" means offering at least Y time slots across Z days, in the candidate's timezone (as defined in the candidate profile unless the candidate specifies otherwise).

Conversation (Mutual)

  • The first conversation must be scheduled and occur within the applicable SLA window(s) measured from mutual affirmation.

  • If the SLA does not define a conversation-occurrence window, the platform applies N days as an operational target for enforcement and UX.

Reschedules and mutual extensions

Ibby is optimized for fast first conversations. Reschedules are allowed, but extensions are intended for exceptional events (travel, illness, holidays, unexpected schedule constraints) rather than a default workflow.

Default rule

  • A handshake may be rescheduled as needed, provided it still satisfies the SLA conversation window.

  • If the SLA conversation window cannot be met, Ibby may allow one mutual extension of up to 5 business days, only when both parties explicitly confirm the extension inside Ibby.

Requirements for an extension

To grant an extension, Ibby requires:

  • Explicit mutual confirmation: both parties must confirm in-product; email/text agreement is not sufficient.

  • A concrete next step: either (a) a scheduled time is confirmed, or (b) the company proposes at least 5 time slots across 3 days (in the candidate's timezone) as part of the extension flow.

If these requirements are not met, Ibby may close the handshake as Unavailable/Closed rather than keep it open-ended.

Limits and abuse prevention

  • Additional extensions beyond the default allowance are not guaranteed. Ibby may apply increased friction, require stronger confirmation, or close the handshake instead.
  • Extensions are tracked as a reliability signal. Repeated extensions, repeated reschedules without confirmed times, or patterns that degrade candidate experience may trigger guardrails for the role (e.g., handshake concurrency limits, cooldowns, throttling, or suspension).

Mutual close

Either party may propose to close the handshake. If both parties agree to close, the handshake is marked Mutual Close and is not treated as a no-show.

Guardrails to Keep "Affirm" Meaningful

The system must ensure "Affirm Interest" is a meaningful commitment.

These reliability-aligned guardrails may be used to prevent patterns that degrade candidate experience (e.g., affirming more conversations than the team can actually schedule and complete).

Ibby can apply one or more of the following controls to reduce abuse and improve handshake reliability:

  • Handshake concurrency limits: cap concurrent Active Handshakes for a role/team
  • Affirm requires scheduling availability: time windows / select slots / calendar link
  • Cooldowns: temporary delay before the next affirmation is allowed after a failure
  • Throttle delivery: slow or pause new QMB delivery when a role is repeatedly failing handshakes
  • Temporary suspension: for repeated no-shows or bad-faith behavior

Verification & Accountability

Default Verification (Two-party Confirmation)

After the scheduled time (or SLA window), Ibby asks both parties:

  • Did the conversation occur? (Yes / No)

Outcomes:

  • Yes + Yes → Completed
  • No + No → Failed (reason selection required)
  • Yes + No → Dispute

Dispute Resolution (Minimal-Proof, Low-Friction)

Disputes should be rare but must be defined.

Allowed evidence (any one):

  • calendar invite / cancellation
  • email thread screenshot
  • call log screenshot
  • "proposed times went unanswered" with timestamps visible

Resolution rule (default bias):

  • Penalize non-response and missed SLA actions over "bad luck."
  • If company never proposed times → company at fault.
  • If candidate never responded to time proposals → candidate at fault.
  • If scheduled and candidate no-showed → candidate at fault (unless company changed details).
  • If scheduled and company no-showed → company at fault.

Representation Integrity (Deception / Misrepresentation)

Ibby does not certify credentials or independently verify claims. Employers retain responsibility for validation (references, work samples, interviews, background checks) as they do today.

What Ibby does enforce is representation integrity: both parties are accountable for materially misleading behavior that wastes time, distorts matching, or creates repeated failed handshakes.

This is bi-directional:

  • Companies can report deceitful candidates.
  • Candidates can report duplicitous companies (bait-and-switch roles, compensation misrepresentation, remote/onsite misrepresentation, hidden dealbreakers, etc.).

What counts as "deception" (material misrepresentation)

Examples (illustrative, not exhaustive):

  • Candidate: fabricated employment/education, inflated scope/responsibilities, false certifications, misrepresented work authorization, knowingly false location/availability, or repeated contradictions after clarification.
  • Company: bait-and-switch (different role/seniority), knowingly false comp/benefits range, misrepresented remote/onsite expectations, misrepresented reporting line/decision authority, or key constraints withheld until after mutual affirmation.

Reporting (low-friction, structured)

After a handshake completes or fails, either party may select:

  • Report deception / misrepresentation
  • Choose category + severity (Minor / Material)
  • Optional freeform note
  • Optional minimal evidence upload (see below)

Important: Reporting is not a substitute for employer verification. Ibby reporting is a governance signal used to protect network quality.

Minimal Evidence (when needed)

Evidence should be lightweight and privacy-respecting. Any one of:

  • call notes excerpt (redacted as needed)
  • job posting / written message excerpt
  • calendar/email excerpt showing key terms (e.g., compensation/remote)
  • screenshot of contradiction (e.g., certification claim vs admission)

Resolution & Dispute Flow (mirrors handshake disputes)

If a report is submitted, Ibby can:

  1. Request clarification from the accused party (simple response window).
  2. Check internal consistency (contradictions across prior claims, prior reports, or interrogation history).
  3. Apply bias toward measurable non-compliance (pattern + repeated reports + refusal to clarify) rather than trying to "prove truth" in a court-like way.

Outcomes:

  • No action: (insufficient signal / good-faith misunderstanding)
  • Warning + education (first-time / minor)
  • Strike recorded (material or repeated)
  • Enforcement applied (see below)

Enforcement (same mechanisms as Handshake compliance)

Misrepresentation uses the same progressive enforcement ladder already defined for handshake failures:

  • Companies: Strike → Throttle → Pricing Pressure → Suspension → Removal
  • Candidates: Nudge/Education → Match Priority Reduction → Cooldown → Extended Cooldowns → Temporary Suspension

Severity and repeat behavior determine how fast escalation occurs. Repeated material deception accelerates progression.

Anti-abuse guardrails (prevent retaliatory reporting)

  • Reports are weighted by reporter reliability (repeat good-faith vs repeat abuse).
  • Repeated false/retaliatory reports count as abuse and can be penalized under the same enforcement model.
  • Ibby prefers structured categories + minimal evidence to reduce "he said / she said" dynamics.

Enforcement

Enforcement exists to protect time and maintain trust. It must be predictable, symmetric, and escalating.

Company Consequences

Applied on failures attributable to the company (ghosting, no-show, missed scheduling SLA).

Progression (illustrative):

  1. Strike + Warning

    • Clear explanation of failure and how to avoid it.

  2. Throttle

    • Longer wait between new match briefs.
    • Reduced number of incoming match briefs.
    • Reduced active handshake capacity.

  3. Pricing Pressure

    • Fee multiplier, higher tier requirement, or per-handshake surcharge.

  4. Suspension

    • Temporary inability to receive new match briefs / initiate handshakes.

  5. Removal

    • Company is dropped from the network for repeated non-compliance.

Candidate Consequences

Applied on failures attributable to the candidate (ghosting, no-show, missed response SLAs).

Progression (illustrative):

  1. Nudge + Education

  2. Match Priority Reduction

  3. Cooldown

    • Cannot affirm new matches for X days.

  4. Extended Cooldowns

  5. Temporary Suspension or termination

Reversible Mistakes & Grace (Fairness Controls)

To avoid brittleness and reduce accidental punishment:

Misclick Undo Window (Required)

  • Company can retract "Affirm Interest" within 10 minutes before candidate is notified (or before mutual binding).
  • Each party gets 1 no-fault reschedule per quarter (or per X handshakes).
  • After grace is exhausted, reschedules count against compliance if they violate SLA.

Good-faith Exit Paths (Required)

Allow exits without penalty when:

  • Role closed legitimately (rare, tracked)
  • Candidate accepted another offer (tracked)
  • Mutual availability impossible despite both meeting scheduling action requirements

Edge Cases (Explicit Rules)

Role filled / req closed after mutual affirmation

  • Company can mark Role Closed.
  • Handshake is voided.
  • If repeated: counts as a strike (prevents bait behavior).

Candidate withdraws (offer accepted, changed circumstances)

  • Candidate can withdraw.
  • Handshake ends.
  • No penalty if withdrawal occurs quickly (e.g., within 24 hours) and is truthful.

No mutual availability

  • If both parties propose times and respond within SLA, but no overlap exists:
  • handshake can expire without fault (recorded as "no-fault availability")
  • If one party fails to propose/respond: fault assigned accordingly.

Time zone confusion

  • System presents all times in candidate's timezone by default.
  • Scheduling changes must be acknowledged; silent changes count as fault.

UX Requirements (How it should feel)

Company Affirmation Screen (Commitment Preview)

Before "Affirm Interest" completes, show:

  • "If candidate affirms, you commit to a first conversation."
  • Expected duration (e.g., 20–30 minutes)
  • Scheduling SLA requirement
  • Conversation SLA deadline
  • Capacity consumption ("This uses 1 of your 3 active handshakes.")

Candidate Affirmation Screen

Show:

  • "If you affirm, the company is committing to a real first conversation."
  • Clear timelines and expectations
  • How to report issues / non-response

Post-handshake Feedback

After completion/failure:

  • 1-tap confirmation
  • Short reason selection on failure
  • Optional freeform note

Metrics (What Ibby Tracks)

Handshake enforcement should produce measurable outcomes.

Core Metrics

  • Handshake Completion Rate (mutual affirmed → completed)
  • Scheduling SLA Compliance (company proposed times within SLA)
  • Time-to-Schedule (mutual affirmed → scheduled)
  • Time-to-Conversation (mutual affirmed → completed)
  • Dispute Rate (handshakes entering dispute state)
  • Repeat Offender Rate (companies/candidates accruing strikes)

Derived Trust Signals

  • Company Reliability Score
  • Candidate Reliability Score
  • Segment reliability averages (for pricing and gating)

Policy Principles

  1. Affirmation is a commitment, not a "like."
  2. Non-response is the primary failure mode and is penalized.
  3. Consequences must be progressive and clearly communicated.
  4. Verification is lightweight but must exist.
  5. Fairness controls (undo, grace, no-fault cases) prevent brittleness.
  6. Symmetry matters: both sides can harm trust; both sides must be accountable.
  7. Bi-directional integrity: Both candidates and companies are accountable for materially misleading representations; either party can report deception, and Ibby applies the same progressive enforcement mechanisms to protect network quality.

Optional Future Enhancements (Not Required for MVP)

  • Calendar integrations (Google/Microsoft) for automatic availability capture
  • Auto-generated scheduling links per handshake
  • Automated reminders and escalation steps
  • "Compliance-based pricing" that updates dynamically
  • Reputation visibility (e.g., "Reliable Company" badge) where appropriate