It’s hard to quantify what is better at this point. From a manual processing standpoint it is a huge improvement.

the lens through which I view this though is clearly different than what you see. I didn’t see any automation in ACE that I considered to be in working order.

 

There was never any API access that ACE used for their Auto-ID. It took MPI/RPH text files and compared rerouted messages. It was never reliably programmed to catch edge cases such as gate returns and diversions. Pay calculations were also not 100% as end of rotation credit calculations were never fully fleshed out.

Also, any programming around 12.D.4 and 8.D.3 when tested returned results that were sometimes sub 50% accurate and still required extra work to validate.

The full capabilities of auto-ID in its end state were essentially generating a list that would need to be manually audited by scheduling committee members to ensure accuracy. It was not a magical automated compliance tool that people wish to believe.

 

Yet somehow UAL managed to implement rather quickly. Have you called them? I'm tired of hearing it's a Delta IT issue. It wasn't like our PWA snuck up on them or anything like that.

 

Well be fair... ACE pre-dated API access by more than a few years. And API access was only negotiated with the current contract, signed in March 2023. It was negotiated specifically with ACE in mind, in collaboration with, and at the behest of 5S.

It takes 2 to tango, and the company gets a vote. DL requires significant data security certifications to access its systems. This cannot be done overnight, and is not cheap to obtain. ALPA only gained real-time API access in what, September 2024? Or thereabouts? Months after ACE got dumped? So throwing shade at the work-around of using text files in the 'meantime' paints a very incomplete picture.

I can't speak intelligently about the workflows/backend of ACE vs. STS. So I'll have to take the volunteers' word for what their work-life was/is like. But I can say that some of the accusations posted here in the last couple of days are wildly inaccurate. Such as the accusation that 5S was attempting to triple their fee. The fact is, the first contract APLA had with 5S was for $5 per user per month, and the second contract was $9 per user. It was the third contract where things fell apart because the MEC decided they wanted to own, not rent.

So I'll again ask if anyone can answer the following:
1. How much money has ALPA spent on multiple vendors getting to the current iteration of STS?
2. How much money did 5S offer to sell ACE to ALPA for (that was turned down)?

I think most of you would be shocked at the answer. Hint: The answer to 2 is less than 1... Regardless of the anything else, the then-MEC chair and admin did ACE dirty.

 

don’t hint. tell us the numbers and a source for them

 

The horse's mouth. That's all you get. Not revealing more than that for my and their protection. If that's not good enough for you, that's fine with me. The facts remain.

 

that’s also how my rep explained it to me.

 

I’ve had one rep explain it that way, and a different rep explain it Fangs’ way. Both staunch in their versions.

 

There are situations where renting is a better option, especially when the service provider is an expert in the field. I suspect the rental model would have both recovered and deterred a significant amount of the current wage theft.

 

For those "in the know", what data did D-ALPA get access to back in Sept 2024? I'm really curious if the data they're given access to is the complete picture?

For example, to audit rotations for reroute you would need to know the rotation "as built" and the rotation "as flown". Another poster mentioned this comes from an MPI and RPH file? From there, if you determine a re-route occurred, and calculate the pay, how do you determine if the reroute was paid? Is the pay data in that data access?

How is the data being delivered? Periodic data dumps? Some type of database connection? HTTP API?

From what I saw in the final breaths of ACE, they were identifying a reroute occurred, and calculating the pay due. However, they then were depending on the pilot to check their timecard and see if that happened. If this were to create a flood of 1,000 ACE tickets every month does scheduling have the bandwidth to work through all of these? How many are false positive scenarios where reroute pay isn't actually due? Eg. gate return, in-flight diversion, etc.