Kicking Off the Atlas Flagship Software Schedule

Good morning, everyone, and thanks for joining on short notice. I think we have everybody, but let me do a quick roll call so we know who owns what from day one. I'm Hyejin from Program Management, and I'll be the software program manager for Atlas. Daniel, Sora, could you introduce yourselves first?

Sure. I'm Daniel, technical lead for Kernel and BSP. My team will own bring-up on the new Arvenna chipset, the kernel branch, and all the low-level drivers, so anything that touches the bootloader, power management, or storage will probably land on my desk.

And I'm Sora, also from Kernel and BSP. I'll be handling the integration side, which means merging vendor drops, keeping our patches rebased, and making sure the daily build actually boots. Daniel is the architect; I'm more of the plumber.

I'm Rachel from Platform Framework. We cover the Android framework layer, system services, and the vendor interface. On Atlas, my biggest interest is how early we get a stable BSP, because every framework feature we plan is blocked until the hardware abstraction layers are in place.

Hi, I'm Ethan from SQE, software quality engineering. My team designs the test plans, runs the stability and regression campaigns, and ultimately signs off on each milestone. I'll be honest, I'm here today mostly to make sure the quality gates are written into the schedule rather than added at the end.

Perfect, that's exactly the mindset I want. Here's the agenda. First, I'll give some background on Atlas and the commercial target. Second, we'll walk through a draft milestone plan and challenge it. Third, we'll talk about risks and dependencies. And finally, we'll confirm owners and the next checkpoint. We have an hour, so let's try to keep each part tight.

So, background. Atlas is next year's flagship, and the business has committed to a market launch on March 12th, 2027. That date is announced internally and the marketing plan is built around it, so please treat it as fixed. What we control is everything between today and that date. The headline change from Orion is the new Arvenna chipset, plus a move to a newer kernel branch.

Can I add some context there? The new chipset is not just a speed bump. Arvenna redesigned the power management controller, and the memory controller is new as well. In my experience, those two areas account for most of the early instability. So when we look at the schedule, I'd like us to be realistic about how long bring-up will take.

Noted, and that's a good segue. Let me share the draft. The first Arvenna BSP drop is promised for August 14th. Development officially starts on Monday, August 17th. We target first boot on proto hardware by September 7th, EVT software by October 19th, feature complete on December 4th, code freeze on January 22nd, and the final release candidate on February 5th.

Just to clarify, when you say first boot on September 7th, do you mean booting to the Android home screen, or just getting a kernel console? Those are very different milestones, and I've seen people celebrate a console prompt while the display, storage, and USB were all still broken.

Fair question. My draft says boot to home screen with display and touch working. Is that too aggressive?

Honestly, yes, if the BSP lands on the 14th. That gives us roughly three weeks, and the proto boards don't arrive in Korea until August 24th according to the hardware team. So realistically we'd have two weeks on real hardware. I'd push back on that. My proposal is to split it into two checkpoints: kernel console by September 7th and home screen by September 21st.

I understand the hardware constraint, but from the framework side, two extra weeks without a booting system really hurts. My team is planning to start integrating the new camera and display features in September. If we can't boot to home until the 21st, we lose about a third of our integration window before EVT.

I hear you, Rachel, but committing to a date we're likely to miss doesn't help you either. What if we give your team early access to the reference board? Arvenna ships an evaluation board that already runs their BSP. It's not our hardware, but it's close enough for framework development in the meantime.

That could work, as long as we get enough units. How many evaluation boards do we have?

We have six today, and four of them are reserved for kernel bring-up. I could free up two for your team immediately, and I'll ask Arvenna for another batch of ten. Their lead time is usually about two weeks, so we'd have them before the end of August.

Can I jump in on the later milestones? I'm less worried about September and more worried about the gap between feature complete and code freeze. December 4th to January 22nd looks like seven weeks, but it includes the year-end holidays. In practice, we lose at least a week and a half, and that's exactly when SQE needs to run the full stability campaign.

How long does the full stability campaign need, end to end?

For a new chipset, I'd want four full cycles. Each cycle is about a week: a 72-hour stress run on two hundred devices, then triage and a fix build. If the defect count is still trending down after cycle three, we can be flexible. But I'm not comfortable signing off on a new platform with fewer than three cycles.

Then the obvious question is whether feature complete can move earlier. My team could commit to November 27th instead of December 4th, but only if we really do get a booting device in mid-September. Those two things are tied together.

I like where this is going. Let me try to summarize the trade-off. If we split first boot into console on September 7th and home screen on September 21st, and Rachel's team gets evaluation boards in the meantime, framework can pull feature complete in to November 27th. That gives SQE one extra week before the holidays. Does that hold together for everyone?

It does for kernel, with one caveat. Everything we just said assumes Arvenna delivers on August 14th. If their drop slips, the whole chain moves. I'd like a contingency trigger in the plan, something like: if the BSP is more than five working days late, we escalate to their account management and replan.

That's a very reasonable trigger, and I'll put it in the risk register. Let's stay on risks for a moment. Apart from the BSP date, what keeps you up at night?

For me, it's the kernel branch move. We're carrying around three hundred out-of-tree patches from Orion. Some of them will apply cleanly, but a lot of them touch scheduler and memory code that changed upstream. I estimate four to six weeks of rebasing and retesting, running in parallel with bring-up. If I'm the only person on it, that's a single point of failure.

Agreed. I can move one more engineer onto the rebase from the Orion Fold team once their launch wraps up in mid-September. Until then, Sora, let's prioritize ruthlessly. Anything that's not needed for boot, display, or storage can wait.

On my side, the dependency is Google. The Atlas schedule assumes we ship on the next Android release, and Google's public timeline for the final platform build is still a little vague. If their release slips by a month, our feature complete date doesn't mean much, because we'd be building on a moving base.

Good point. I'll set up a separate session with our Google partner engineering contact to get their milestone dates in writing. Ethan, anything from the quality side beyond the holiday gap?

Two things. First, test device allocation. Two hundred devices for the stability campaign means we need DVT hardware by mid-December at the latest. Second, I want a written definition of done for each milestone. Last year we had a lot of debate about whether EVT was really complete, and it cost us time. If we agree on the exit criteria now, nobody has to argue later.

Couldn't agree more. Can you draft exit criteria for EVT and feature complete, and circulate them by next Friday? Keep it measurable: open blocker count, crash rate per thousand hours, that kind of thing.

Will do. I'll base it on the Orion criteria and adjust the thresholds for a new chipset.

There's one more risk I want on the record, even if we can't do much about it today. Arvenna's thermal characterization for the new chipset won't be final until October. Until then, our thermal and power management tuning is based on preliminary data. If the final numbers come in worse, we could see throttling problems late in the program, which is the worst possible time.

Understood. Let's log it as a known risk with an October review date, and ask Arvenna whether they can share interim measurements earlier. Even partial data would help us avoid surprises.

I can raise that in the first vendor sync. They usually have bench data long before the official report is signed off.

Before we lock the decisions, I want to spend ten minutes on how we work together, because in my experience, schedules rarely fail on technology alone. They fail when issues sit in somebody's queue for a week and nobody notices. So, how do we want to triage bugs during bring-up?

During bring-up, I'd suggest a short daily triage, fifteen minutes, kernel and BSP plus whoever is blocked. Not a status meeting, just a quick pass over new issues to assign an owner and a priority. The rule should be that no new blocker goes more than one working day without an owner.

I'd add one thing to that. Every issue SQE files will include the build number, the reproduction rate, and logs attached at the time of filing. In return, I'd ask developers not to close issues as 'cannot reproduce' without talking to us first. Half the time, the difference is a test condition that wasn't obvious from the ticket.

That's fair, and honestly it goes both ways. If you can give us the exact test script, we can often reproduce it on our own bench instead of borrowing your devices. That would take a lot of pressure off the device pool, which is going to be tight until DVT.

From the framework side, my concern is visibility into vendor issues. When something is stuck with Arvenna, we usually find out late, because the ticket lives in their portal and not in our tracker. Could we mirror vendor tickets into our system so everyone can see the status in one place?

We tried a full mirror on Orion and it was more noise than signal. What worked better was a weekly vendor sync where we only review tickets that block one of our milestones. I'd propose we do that again and publish a short list of top vendor blockers after each sync.

That works for me, as long as the list is actually published. I don't need every detail; I just need to know when to stop waiting and start working around a problem.

Good, so we have three working agreements: a fifteen-minute daily triage during bring-up, no 'cannot reproduce' closures without talking to SQE, and a weekly vendor sync with a published blocker list. I'll capture those in the program charter so new team members can find them later.

Great. Let me read back the decisions so we're all on the same page. One: development starts on August 17th. Two: first boot is split into kernel console by September 7th and home screen with display and touch by September 21st. Three: framework feature complete moves to November 27th. Four: code freeze stays on January 22nd and the final release candidate on February 5th. Any objections?

No objection, as long as the evaluation boards show up on time.

Understood, and that's an action item. Here are the owners. Sora: hand two evaluation boards to Rachel's team by Tuesday and request ten more from Arvenna this week. Daniel: confirm the August 14th BSP date with Arvenna in writing by Wednesday. Ethan: circulate draft exit criteria by Friday, August 7th. Rachel: share the framework integration plan against the new dates by the same Friday. And I'll set up the Google timeline call and update the risk register with the BSP escalation trigger.

One small request. Can we also agree on a weekly build health report? Just a one-page summary of whether the daily build boots, which tests pass, and what's blocking. It saves a lot of hallway questions.

Great idea. Sora, would you own that, starting from the first week of development? Every Friday afternoon.

Happy to.

Then let's wrap up. Thank you all for pushing back where it mattered. I'd much rather adjust the plan today than discover in November that it was never realistic. Our next checkpoint is Saturday, August 8th, at 10 a.m. Korea time, same meeting room and the same video link. By then, I expect the BSP date confirmed and the exit criteria drafted.

Sounds good. I'll ping Arvenna right after this call.

Thanks, Hyejin. This was a productive kickoff. See you all next week.