Lazerite Ramp to Avoca FDE (proposal)

Source and status

• Source: Lazer-side proposal, captured from the shared Drive
• Status: proposal, not adopted policy
• Captured into the toolkit: 2026-05-12 by Sandy Corsillo (framing reworked 2026-05-18)

This proposes how Lazer engineers placed at Avoca ramp into the engagement. The current operating model is described in Lazer FDE Onboarding.

How to read this

The framing: Lazerites should become full Avoca FDEs. There is a ramp to get there. This document specifies what that ramp looks like — what work the Lazerite picks up at each stage, who reviews it, and when they are ready to operate as a full Avoca FDE.

The proposal is opinion-shaped, not reference-shaped. Sections 1 through 4 build the argument; section 5 lays out the concrete five-phase ramp; sections 6 through 14 specify role boundaries, the ticket template, PR policy, principles, and risks. Skim section 5 first if you want the actionable shape.

Executive Summary

Lazerites placed at Avoca should become full Avoca FDEs. There is a ramp to get there. This proposal defines that ramp.

The end state isn't a separate "Lazer FDE" identity that's permanently distinguishable from Avoca FDEs by capability. The end state is Avoca FDE — full ownership of customer context, client-facing judgment, and implementation direction. The Lazerite label is contractual (who employs the person), not capability-based.

Three operating categories:

1. Avoca FDE — the end state. Whether direct-hire Avoca or fully-ramped Lazerite, this person owns customer context and client-facing judgment for their accounts.
2. Ramping Lazerite — a Lazer placement still building Avoca-specific product, customer, prompt, integration, and codebase context. Transitional, not permanent.
3. Avoca PE — Platform Engineer. Separate role: shared product and platform direction across customers, not a destination for Lazerites.

The core problem the ramp addresses: a Ramping Lazerite gets treated like a full Avoca FDE too early, placed onto client-facing or time-sensitive work before they have the context to handle it safely. The result:

• Slower delivery
• More back-and-forth
• More review burden for Avoca FDEs
• Higher risk of customer-impacting mistakes
• Increased anxiety for the Lazerite mid-ramp
• Less predictable quality

The fix: a staged ramp that starts a Ramping Lazerite on prompt engineering and call-flow work before they take on higher-context implementation streams (integrations, backend workflows, dashboard/product, QA, internal tooling).

Prompt engineering is the right first workstream because it is the highest-touch point of Avoca's product. For customers, the voice agent's behavior IS the product. If quality slips in the prompt layer, the impact is immediately felt by customers and callers. The Ramping Lazerite learns Avoca from the customer-facing layer inward, with each phase expanding their owned surface area until they are operating as a full Avoca FDE.

1. Recommended Role Taxonomy

Three operating categories. The Lazerite ramp moves a person from category 2 (Ramping Lazerite) to category 1 (Avoca FDE). Category 3 (Avoca PE) is a separate role, not a destination for Lazerites.

Avoca FDE (end state)

The full FDE role. Owns customer context, client-facing technical judgment, and implementation direction for assigned accounts. Closest to the customer, AE, CS, and GTM teams.

Whether direct-hire by Avoca or fully-ramped Lazerite, the responsibilities are the same:

• Understanding customer requirements
• Managing customer-specific technical context
• Working with AEs, CS, and GTM
• Translating ambiguous customer asks into scoped work
• Prioritizing urgency and customer impact
• Reviewing high-risk customer-impacting changes
• Deciding when something is client-ready
• Providing implementation context to Ramping Lazerites
• Protecting customer trust
• Owning technical confidence in client-facing settings

Avoca FDEs are context owners, not generic reviewers. A Lazerite reaching this state has earned the same trust and ownership boundaries as a direct-hire Avoca FDE.

Ramping Lazerite (transition state)

A Lazer engineer placed at Avoca, still building Avoca-specific product, customer, prompt, integration, and codebase context. Not yet independent Avoca delivery capacity. Needs a protected ramp that gives product fluency before being handed urgent, ambiguous, or high-risk customer-facing work.

A Ramping Lazerite is moving toward Avoca FDE. Their work expands across the ramp's phases (see section 5) — starting from prompt engineering and call-flow, then supervised customer-account work, then full FDE ownership.

What a Ramping Lazerite focuses on early:

• Access setup
• Product orientation
• Prompt builder training
• Prompt engineering work
• Call-flow modification
• Testing workflows
• QA standards
• Shadowing Avoca FDEs
• Gradual exposure to one customer account
• Learning how Avoca translates customer requirements into agent behavior

What a Ramping Lazerite should NOT own immediately:

• Urgent production fixes
• Ambiguous client asks
• Independent client communication
• High-risk integration changes
• Broad platform changes
• Client-facing technical judgment
• Large PRs
• Work without clear acceptance criteria

The purpose of the ramp is not just to give someone access. It is to build enough Avoca-specific context for them to safely operate as an Avoca FDE.

Avoca PE (separate platform role)

Avoca Product Engineers own the shared product and platform surface area. Not a destination for Lazerites — a distinct role that operates across customers rather than owning specific customer relationships.

Involved when work becomes productized, architectural, shared across customers, or connected to core platform direction.

Avoca PEs are responsible for:

• Product architecture
• Core platform patterns
• Dashboard/product changes
• Shared abstractions
• Reusable systems
• Productized versions of repeated customer requests
• Codebase direction
• Review of changes that affect shared systems
• Technical standards across the product

If Avoca FDEs own customer context, Avoca PEs own platform and product direction.

2. Problem Statement

The current ramp model risks treating Onboarding Lazer FDEs like Lazer FDEs too early.

This creates several problems.

2.1 Onboarding Lazer FDEs lack Avoca-specific context

Even strong engineers need time to learn:

• Avoca's voice agent behavior
• Prompt structure
• Call-flow logic
• Customer expectations
• CRM/integration patterns
• Internal terminology
• Codebase conventions
• Review expectations
• Testing norms
• What can and cannot be said to customers
• Which systems are internal-only
• Which changes are high risk
• Which changes are safe and reversible

Without this context, even simple-looking work can become risky.

2.2 Client-facing work becomes slower, not faster

The goal of adding Lazer FDE capacity is to increase delivery velocity.

But when someone is not ramped, the opposite can happen:

• More clarification is needed
• Avoca FDEs are interrupted more often
• Review cycles become heavier
• PRs require more rework
• Customer context has to be re-explained repeatedly
• The Onboarding Lazer FDE becomes anxious
• The Avoca FDE becomes the bottleneck anyway

The issue is not capability. The issue is sequencing.

A strong engineer can still become ineffective if they are pushed into high-context work before they have the right ramp.

2.3 FDEs remain the bottleneck without getting the benefit

If an Onboarding Lazer FDE is assigned ambiguous client-facing work, the Avoca FDE still has to:

• Explain the customer context
• Clarify the requirement
• Review the implementation
• Validate the behavior
• Manage client expectations
• Catch edge cases
• Coordinate release risk

That means the Avoca FDE is not actually being leveraged less. They are being context-switched more.

The better model is for Avoca FDEs to distill client context into structured internal work that Lazer FDEs can execute safely.

2.4 High-context code work is risky early in onboarding

Code changes can look small but carry hidden risk.

A small backend or integration change may require understanding:

• Which customer account is affected
• Whether the logic is client-specific or shared
• Whether the workflow uses legacy or centralized routing
• Whether the change affects booking, rescheduling, cancellation, or lead creation
• Whether the CRM sandbox is reliable
• Whether the customer has unusual business rules
• Whether the requested change is actually in the customer's best interest

That is too much hidden context for a brand-new Onboarding Lazer FDE to infer independently.

3. Proposed Solution

Create a staged Lazer FDE Ramp Model.

The model should move Onboarding Lazer FDEs from low-context, controlled work toward higher-context, higher-leverage work.

The progression should be:

1. Access and orientation
2. Prompt engineering and call-flow foundation
3. Supervised customer-account work
4. Specialization stream
5. Graduation to Lazer FDE

The core principle:

Onboarding Lazer FDEs should first learn how Avoca behaves before they are asked to change how Avoca works.

4. Why Prompt Engineering Should Be the First Workstream

Prompt engineering should be the first onboarding workstream because it is the highest-touch point of Avoca's platform and product offering.

For customers, the agent's behavior is the product.

The prompt determines how the agent:

• Greets callers
• Asks questions
• Confirms information
• Handles ambiguity
• Reads information back
• Adjusts pacing
• Responds to confusion
• Escalates edge cases
• Books appointments
• Handles rescheduling
• Handles cancellations
• Represents the customer's business

If quality slips here, the impact is immediately visible to customers and callers.

A bad prompt change can create:

• Awkward calls
• Robotic phrasing
• Incorrect read-backs
• Poor caller experience
• Lower customer trust
• Missed booking intent
• Confusing call flow
• Bad escalation behavior
• More customer complaints
• More manual review for Avoca

That makes prompt engineering both a strong onboarding surface and a critical quality-control function.

4.1 Prompt work teaches product behavior from the outside in

Prompt engineering lets Onboarding Lazer FDEs learn Avoca from the customer-facing layer inward.

They learn:

• What the caller experiences
• What the customer cares about
• How requirements translate into agent behavior
• How small changes affect call quality
• How Avoca thinks about tone, pacing, and information capture
• How to test changes against realistic scenarios
• How to reason about product quality without immediately touching deeper platform code

This is more valuable than starting with isolated code tickets because it builds product judgment first.

4.2 Prompt work is lower code complexity but not low importance

Prompt work is often easier to constrain than backend or integration work.

It is usually:

• Easier to scope
• Easier to review
• Easier to compare before/after
• Easier to test with known scenarios
• Easier to roll back
• Less dependent on deep codebase context

But that does not make it junior work.

Prompt engineering is customer-experience work. It sits directly on the layer customers feel most.

The framing should not be:

Start with prompts because they are easy.

The framing should be:

Start with prompts because they teach Avoca product behavior at the layer where quality matters most.

4.3 Prompt engineering creates the foundation for later specialization

Once an Onboarding Lazer FDE understands prompt behavior and call flows, they are better prepared to move into:

• Custom integrations
• Backend workflows
• Dashboard/product work
• QA
• Internal tooling
• Customer-specific debugging

They will have a better understanding of why the deeper implementation work matters.

They will also be better at identifying whether a customer issue is caused by:

• Prompt wording
• Call-flow structure
• Tool configuration
• CRM integration logic
• Backend workflow behavior
• Product limitation
• Customer misunderstanding
• Testing gap

That diagnostic ability is essential for becoming an effective Lazer FDE.

5. Lazer FDE Ramp Model

Phase 1: Access and Orientation

Audience

Onboarding Lazer FDEs

Goal

Get the Onboarding Lazer FDE access to the right systems and introduce them to Avoca's product, workflow, and operating norms.

Access includes:

• GitHub
• Avoca email
• 1Password
• Vercel
• Vapi
• Supabase
• Asana
• Notion
• Twilio
• Datadog
• Avoca admin
• Ngrok
• Claude
• Cursor
• ChatGPT

Orientation should cover:

• What Avoca does
• What Responder is
• What FDEs own
• What PEs own
• How customer work is tracked
• How prompt work is done
• How call flows are tested
• How PRs are reviewed
• Which systems are internal-only
• Which information should not be exposed to customers
• Where to ask questions
• How to escalate blockers

Outcome

The Onboarding Lazer FDE can navigate Avoca's environment safely and understands the basic operating model.

Phase 2: Prompt Engineering and Call-Flow Foundation

Audience

Onboarding Lazer FDEs

Goal

Help the Onboarding Lazer FDE understand Avoca's product behavior at the customer-facing layer.

Focus areas:

• Prompt builder
• Booking prompt structure
• Read-back behavior
• Agent pacing
• Call-flow logic
• Fallback handling
• Escalation language
• Customer-specific wording
• Testing prompt behavior
• Before/after documentation
• Common prompt failure modes

Example training tasks:

• Review an existing prompt and explain its structure
• Make a read-back more concise
• Slow down a confirmation step
• Improve awkward phrasing
• Add a fallback when the caller is unsure
• Modify a call flow so the agent confirms one piece of information before moving on
• Make the agent ask one question at a time
• Improve escalation wording
• Test the change against sample calls
• Document the expected behavior change

Outcome

The Onboarding Lazer FDE understands how Avoca agents behave and can make controlled prompt/call-flow changes with review.

Phase 3: Supervised Customer-Account Work

Audience

Onboarding Lazer FDEs

Goal

Give the Onboarding Lazer FDE exposure to real customer work without making them independently responsible for client-facing ambiguity.

Work should be scoped by:

• An Avoca FDE, or
• A Lazer FDE who has sufficient context

Appropriate work:

• Prompt updates
• Call-flow changes
• Minor customer-specific behavior adjustments
• Testing known scenarios
• Documenting observed behavior
• Small bug fixes with clear acceptance criteria
• Assisted debugging

Guardrails:

• No independent client ownership
• No direct client communication unless explicitly approved
• No high-risk production changes without Avoca review
• No vague tickets without clarification
• Testing notes required
• Small PRs preferred
• Risky changes escalated to Avoca FDEs or Avoca PEs

Outcome

The Onboarding Lazer FDE can execute scoped work in a real customer context with support.

Phase 4: Specialization Stream

Audience

Onboarding Lazer FDEs moving toward full Lazer FDE status

Goal

Move the person into a deeper Avoca capability area after they have developed product fluency through prompts and call flows.

Possible specialization streams:

1. Prompt engineering and conversation design
2. Custom integrations
3. Dashboard/product support
4. Backend workflow logic
5. QA and release validation
6. Internal tooling

Specialization Stream A: Prompt Engineering and Conversation Design

This stream is for Lazer FDEs who are strong in language, product behavior, QA, and call-flow logic.

Responsibilities:

• Own prompt changes
• Improve prompt templates
• Maintain prompt best practices
• Build reusable prompt patterns
• Support Avoca FDEs with conversation design
• QA agent behavior
• Create test scenarios
• Identify repeated prompt issues across customers

This should be treated as a serious specialization, not as junior work.

Specialization Stream B: Custom Integrations

This stream is for Lazer FDEs who are ready to handle customer-specific integration work.

Responsibilities:

• Build or modify integrations
• Work from Avoca FDE-scoped requirements
• Handle API mapping
• Debug CRM behavior
• Document integration assumptions
• Support integration QA
• Identify reusable integration patterns

This stream should come after the Lazer FDE has learned how Avoca agents behave in real customer workflows.

Specialization Stream C: Dashboard/Product Support

This stream is for Lazer FDEs who can support dashboard and product-adjacent work.

Responsibilities:

• Dashboard UI changes
• Product bug fixes
• Admin workflow improvements
• Data display improvements
• Internal tooling
• Productized versions of repeated client requests

This stream should involve Avoca PEs when work affects shared product behavior or architecture.

Specialization Stream D: Backend Workflow Logic

This stream is for Lazer FDEs working on post-call workflows, booking logic, CRM updates, and related backend behavior.

Responsibilities:

• Modify backend workflows
• Debug booking/rescheduling/cancellation logic
• Understand centralized vs. direct webhook paths
• Update CRM writeback behavior
• Improve workflow reliability
• Document customer-specific assumptions

This stream requires stronger codebase context and should not be the first onboarding surface.

Specialization Stream E: QA and Release Validation

This stream is for Lazer FDEs who are detail-oriented and strong at testing.

Responsibilities:

• Regression testing
• Prompt behavior testing
• Call-flow test cases
• Release validation
• Bug reproduction
• QA documentation
• Test scenario maintenance

This is especially important because prompt and voice-agent changes need careful validation.

Phase 5: Graduation to Lazer FDE

Audience

Onboarding Lazer FDEs who have completed the ramp

Goal

Confirm that the person can safely operate as a Lazer FDE inside Avoca's delivery model.

Graduation criteria

An Onboarding Lazer FDE should become a Lazer FDE once they can consistently:

• Navigate Avoca's tools and workflows
• Understand the difference between prompt, config, integration, backend, and product changes
• Execute scoped tickets independently
• Ask clear clarifying questions
• Identify risk level
• Make small, reviewable PRs
• Write clear testing notes
• Test prompt/call-flow behavior
• Avoid exposing internal tools or implementation details to customers
• Know when to escalate to an Avoca FDE
• Know when to involve an Avoca PE
• Work within customer-specific context without needing constant handholding

Outcome

The person is no longer treated as onboarding. They are now a Lazer FDE who can execute scoped Avoca work independently.

6. Updated 3-Ticket Pairing Model

The existing 3-ticket pairing model is a good foundation, but it should be reframed around Onboarding Lazer FDE progression.

Ticket 1: Observe and Explain

The Avoca FDE or Lazer FDE leads.

The Onboarding Lazer FDE should:

• Observe the workflow
• Ask questions
• Understand the customer context
• Explain the current behavior
• Identify what is changing and why
• Contribute small pieces where appropriate

Success means they can explain the work, not necessarily lead it.

Ticket 2: Co-Own with Support

The Onboarding Lazer FDE and Avoca/Lazer lead work together.

The Onboarding Lazer FDE should:

• Make part of the change
• Write testing notes
• Identify risks
• Ask clarifying questions
• Participate in review

Success means they can contribute meaningfully with support.

Ticket 3: Lead a Scoped Change

The Onboarding Lazer FDE leads a clearly scoped ticket.

The Avoca FDE or Lazer FDE provides support.

The Onboarding Lazer FDE should:

• Clarify the requirement
• Implement the change
• Test the behavior
• Document before/after
• Submit for review
• Escalate any ambiguity

Success means they can own a scoped change without needing step-by-step guidance.

After Ticket 3: Continue Ramp or Graduate

Completing three tickets should not automatically make someone a Lazer FDE.

Instead, it should trigger a readiness review.

Possible outcomes:

1. Continue onboarding with more scoped work
2. Move into a specialization stream
3. Graduate to Lazer FDE
4. Identify specific gaps to close

7. Role Boundaries and Handoff Model

Avoca FDEs Own Context

Avoca FDEs should own ambiguous customer context.

They should answer:

• What does the customer actually need?
• Why does it matter?
• How urgent is it?
• What is the expected behavior?
• What should not change?
• What risks should the implementer know?
• Who needs to review this?
• Is this client-specific or product-level?

Lazer FDEs Own Scoped Execution

Lazer FDEs should own implementation when requirements are clear.

They should answer:

• What needs to change?
• Where should the change be made?
• How should it be tested?
• What edge cases exist?
• What did I change?
• What risks remain?
• Who needs to approve this?

Onboarding Lazer FDEs Own Learning and Controlled Execution

Onboarding Lazer FDEs should not be put into vague ownership situations.

They should be given:

• Clear tickets
• Clear context
• Clear reviewer
• Clear acceptance criteria
• Clear testing expectations
• Clear escalation path

Avoca PEs Own Shared Product/Platform Direction

Avoca PEs should be involved when:

• A change affects shared product behavior
• A repeated customer ask should become a reusable feature
• A dashboard/product change is needed
• A code path is architectural
• A change affects multiple customers
• A new abstraction may be required
• Technical debt or platform direction is involved

8. Internal Ticket Template

To make this model work, Avoca FDEs and Lazer FDEs need structured handoffs.

Use this template for Avoca FDE → Lazer FDE ticket handoffs:

## Request Summary

What needs to change?

## Customer / Account

Which customer or account is this for?

## Context

Why does this matter?

What customer requirement or issue is driving the change?

## Current Behavior

What happens today?

## Desired Behavior

What should happen instead?

## Work Area

- Prompt

- Call flow

- Configuration

- Integration

- Backend workflow

- Dashboard/product

- QA/testing

- Internal tooling

## Scope

What is included?

## Non-Goals

What should not be changed?

## Acceptance Criteria

- [ ] Expected behavior is implemented

- [ ] Relevant test scenarios pass

- [ ] No known regression in related flow

- [ ] Testing notes are included

- [ ] Reviewer has enough context to validate the change

## Test Scenarios

1.

2.

3.

## Risk Level

Low / Medium / High

## Reviewer

Who should review or approve this?

## Escalation Path

Who should be contacted if the request is ambiguous or risky?



9. PR and Review Policy

For Onboarding Lazer FDEs

• All PRs require review from an Avoca FDE, Avoca PE, or designated Lazer FDE
• PRs should be small and focused
• Testing notes must be thorough
• Prompt/call-flow changes should include before/after behavior
• Risky changes should be flagged explicitly
• Ambiguous requirements should be clarified before implementation

For Lazer FDEs

• Routine scoped changes can be handled more independently
• High-risk customer-facing changes still require Avoca review
• Shared platform/product changes should involve Avoca PEs
• Customer-context questions should go back to Avoca FDEs
• Lazer FDEs may review each other's code for implementation feedback, but approval should come from an Avoca FDE or Avoca PE when the change affects customer behavior, shared product/platform logic, or high-risk workflows

10. What Work Should Go to Whom?

Onboarding Lazer FDEs

Good fit:

• Prompt updates
• Call-flow adjustments
• Read-back changes
• Tone/pacing changes
• Fallback improvements
• Testing prompt behavior
• Documenting before/after behavior
• Small scoped bug fixes
• Assisted debugging

Avoid:

• Urgent production fixes
• Ambiguous client asks
• Direct client ownership
• Large integration changes
• Shared platform changes
• Product architecture decisions
• High-risk backend workflow changes

Lazer FDEs

Good fit:

• Scoped prompt work
• Call-flow implementation
• Customer-specific configuration
• Integration updates
• Backend workflow changes
• Debugging
• QA
• Small product/dashboard changes
• Internal tooling

Escalate when:

• Requirements are ambiguous
• Change affects multiple customers
• Customer asks may not be in their best interest
• Product/platform behavior is affected
• There is architectural uncertainty
• The change is high-risk or hard to roll back

Avoca FDEs

Good fit:

• Customer context
• AE/CS/GTM alignment
• Client-facing technical judgment
• Requirement clarification
• Scoping
• Prioritization
• Review of customer-impacting changes
• Approval of risky behavior changes

Avoid overloading with:

• Repetitive implementation details
• Constant ad hoc context explanation
• Review of poorly scoped work
• Tasks that could be handled by a Lazer FDE with better ticket structure

Avoca PEs

Good fit:

• Shared product behavior
• Dashboard/product architecture
• Platform abstractions
• Core codebase changes
• Reusable features
• Technical design
• Review of changes affecting shared systems

11. Operating Principles

Principle 1

Onboarding Lazer FDEs should first learn the layer of the product that customers feel most directly.

That layer is prompt behavior and call flow.

Principle 2

Prompt engineering is not junior work. It is customer-experience work.

The prompt layer directly shapes the customer's perception of Avoca.

Principle 3

Avoca FDEs own customer context. Lazer FDEs own scoped execution. Avoca PEs own shared product/platform direction.

This is the cleanest role boundary.

Principle 4

Onboarding should move from low-context, low-blast-radius work to high-context, high-leverage work.

The goal is not to keep people on simple work forever. The goal is to sequence learning safely.

Principle 5

A Lazer FDE should not need perfect context, but they do need enough context to know when to ask better questions.

Graduation is about judgment, not just task completion.

12. Success Metrics

The onboarding model is working if:

• Onboarding Lazer FDEs become productive faster
• Avoca FDEs spend less time re-explaining context
• PR review cycles are smoother
• Prompt changes include better testing notes
• Customer-impacting regressions decrease
• Lazer FDEs ask better clarifying questions
• More work can be routed through structured tickets
• Avoca FDEs can focus more on customer and AE management
• Avoca PEs are only pulled in when product/platform ownership is needed
• Onboarding feels less chaotic and less anxiety-inducing

13. Risks and Mitigations

Risk 1: Prompt work gets treated as low-status work

Mitigation

Frame prompt engineering as customer-experience ownership. It is the highest-touch surface of the product and should have clear standards.

Risk 2: Onboarding Lazer FDEs get stuck in prompt work

Mitigation

Create explicit graduation criteria and specialization paths. Prompt work is the foundation, not the ceiling.

Risk 3: Avoca FDEs do not provide enough context in tickets

Mitigation

Use the structured ticket template. Require current behavior, desired behavior, acceptance criteria, risk level, and test scenarios.

Risk 4: Lazer FDEs become siloed by specialization

Mitigation

Give each Lazer FDE a primary specialization but maintain baseline product fluency across prompts, workflows, and customer context.

Risk 5: The team assumes three tickets means someone is fully onboarded

Mitigation

Use the three-ticket model as a ramping mechanism, not an automatic graduation rule.

14. Final Recommendation

Avoca should formalize a staged Lazer FDE ramp model.

Onboarding Lazer FDEs should begin with prompt engineering and call-flow work because this is the highest-touch layer of Avoca's platform and the best way to learn product behavior. Once they demonstrate consistency, they can move into specialization streams such as integrations, backend workflows, dashboard/product support, QA, or internal tooling.

Avoca FDEs should remain responsible for customer context and client-facing technical judgment. Lazer FDEs should own scoped execution. Avoca PEs should own shared product and platform direction.

This model creates a clearer ramp, reduces delivery risk, protects Avoca FDE bandwidth, improves Lazer FDE confidence, and gives Avoca a more scalable way to develop high-quality external FDE capacity.

The core framing is:

Onboarding Lazer FDEs need a protected ramp before they are treated like Lazer FDEs.