As AI companies like ChatGPT and Anthropic release new, increasingly intelligent AI models that could potentially replace numerous human roles, what is the anticipated impact on analytics jobs? Given the imminent prospect of AGI-level AI within the next few years, it raises concerns about widespread job displacement.

Sat down last week to redo a client update deck that had gotten messy over four quarters of copy paste. Every slide had a vague label like "Q3 Results" or "Next Steps" sitting on top of a chart nobody could read without me talking over it.

Tried something different this time. Before opening the deck I wrote out what each slide needed to say as an actual sentence. Not a topic. A claim. "Churn dropped because we fixed onboarding" instead of "Retention Update." Once the sentence existed the layout basically built itself. Fewer bullets survived. Charts got simpler because they only had to support one claim instead of hosting a data dump.

Took about half the review cycles this time. Client caught fewer things because there was less to misread.

Do people write the sentence first or build the slide and caption it after the fact?

This is a data reliability story rather than a finance one, and I doubt the shape of it is unique to this source.

The SEC's submissions JSON at data.sec.gov gives every filing an acceptanceDateTime ending in "Z". For a large minority of companies that Z is wrong: the clock in the string is already New York time, not UTC. Read as UTC it puts the filing 4 or 5 hours later than it happened, which in my case was enough to move a row across the 16:00 market close and flip it from intraday to after hours.

So I stopped trusting the JSON and re-read the raw SGML header of each submission instead, where the field ACCEPTANCE-DATETIME is always Eastern, and compared the two record by record: 64,827 filings, every 8-K item 2.02 I could pull for 808 companies, 2003 to 2026. The gap between the two stamps is always exactly 0, 4 or 5 hours. No partial offsets, no noise, nothing in between.

What surprised me was the grain. It is not per record:

• 624 companies converted in every single one of their filings
• 181 in none of them
• 3 mixed, and each of those three differs in exactly one filing, its most recent

The unit is the entity, not the row. That is the difference between re-ingesting everything and building a small lookup table, because a handful of records per entity classifies it.

I want to flag how I got that wrong first, because the mistake is the reusable part. I had already published the opposite conclusion, per record, off a sample of 120 entities. The sample was internally clean and the rule it produced was false, because the counterexamples were entities I had not drawn. The fix was not a better test on the sample, it was counting how many cases would have to exist to break the rule and then going looking for them on purpose.

Two caveats worth being precise about.

I cannot find this field documented anywhere on the SEC's API or developer pages, so this is undocumented behaviour that is inconsistent with itself, not a broken contract. "The API lies" is a stronger claim than the evidence carries.

And the source repairs entries after the fact. Entities that came back unconverted last week come back converted now. Any snapshot is dated, mine is 2026-09-06, and the three mixed entities differing only in their newest filing is that same lag showing up as a fingerprint rather than as a contradiction. It is also why I am not naming a company as an example: a named example expires the moment the source touches that record, and then whoever checks it concludes the rest is wrong too. The method is the part that reproduces.

To check it against whatever you are pulling: take three or four records for one entity, read ACCEPTANCE-DATETIME out of the SGML header, and compare the wall clock against the JSON. If they match, the Z is decoration.

One more, independent of timezones, in case anyone is doing an event study off this field. The acceptance stamp is a ceiling, not the event. Allowing 15 minutes between the press release and acceptance, 8,756 of the 27,227 rows that look like they landed after the close were most likely intraday, about a third of them. The error only runs one way, so a correct time based split survives it, but it is not zero.

Do you:

• Pick a domain you’re genuinely interested in and build projects around it?
• Choose a domain that matches your educational background?
• Or simply take the first Data Analyst opportunity you get and specialize later?

Would love to hear from experienced Data Analysts: does domain specialization actually matter when applying for your first DA job, or is getting that first job more important?

So I've been working with a startup on a web app. It was developed using spec-driven development, and my role was mostly focused on project management (planning meetings, generating reports, coordination...) and helping with other things such as testing.

Soon, I'll start applying for roles in data engineering and data analytics, but I'm not sure which parts of this work are related to data and could help me later on when putting together my resume.

I appreciate your help and advice in advance!