“I Moved” Is Not a Tax Fact

You know how people describe a move after it's over.

“We moved to Brooklyn in July.”

Clean. Certain. One sentence.

It wasn't like that in April.

In April, maybe you were still in California.

The New York job was real, but the apartment wasn't.

You were looking at neighborhoods from 3,000 miles away. Flying back and forth. Talking about when to go. Figuring out whether your spouse would come immediately or a month later. Deciding what to do with the California house.

Maybe your employer wanted you in New York before you were ready to call New York home.

Maybe there was a bonus coming.

Maybe stock was vesting later in the year.

Maybe there was a transaction you knew was coming but hadn't happened yet.

Ask you in April when you moved to New York and you'd probably say:

“I haven't. We're figuring it out.”

Ask you the following February?

“July.”

Same person.

Same move.

Very different information.

That's where our tax research became something else.

Because a tax return eventually needs to describe what happened.

But a decision system has a harder job.

It has to understand what is happening while the answer is still changing.

One move. Three taxing jurisdictions.

Let's stay with California to Brooklyn.

It's useful because there is nowhere for the complexity to hide.

California has an income tax.

New York State has an income tax.

And becoming a New York City resident can introduce another resident income-tax layer.

So somewhere inside this very human process of moving across the country, there are potentially three different jurisdictional questions being asked.

California needs to know when California residency ended.

New York needs to know when New York residency began.

New York City introduces its own resident-tax consequences once city residency applies.

And none of those questions necessarily tells us how every individual item of income should be treated.

That's where sourcing enters.

A person can stop being a resident of one state without making every tax connection to that state disappear.

Wages can raise work-location questions.

Equity compensation can carry a service history.

Business income can have its own connections.

Different transactions can have different sourcing rules.

Suddenly:

“We moved to Brooklyn in July.”

isn't an answer.

It's the beginning of the interview.

Now put some money in the middle of it.

This is where the problem stops being academic.

Imagine our move looks something like this.

Now ask:

When did you move?

July still feels pretty good.

But that's not specific enough anymore.

When did California residency end?

When did New York residency begin?

When did New York City residency begin?

Where were services performed during the transition?

And what actually happened in October?

A bonus?

An equity event?

A stock sale?

Business income?

Something else?

Because even after we establish where this person lived, we still aren't necessarily done.

The type of income can change the analysis.

Which jurisdiction or jurisdictions have a claim to it?

Does residency control?

Does sourcing matter?

Does an earlier service period matter?

Are credits relevant?

Which facts establish the answer?

And here's the question we became much more interested in:

Which of those facts were still open when you were sitting in California in April?

Because that's a different problem.

February and April don't have the same options.

Imagine first meeting this person in February.

The year is over.

The flights happened.

The days happened.

The lease was signed when it was signed.

The work was performed where it was performed.

The household moved when it moved.

The California residence was surrendered when it was surrendered.

The October income event happened.

There is still important work to do.

The facts need to be established.

The law needs to be applied.

Income may need to be sourced or allocated.

Credits may need to be considered.

Documents may need to support a position.

Uncertainty may still require professional judgment.

Historical does not mean irrelevant.

And it certainly doesn't mean nothing can still be done.

But history has one inconvenient property:

You can't make it unhappen.

Now go back to April.

The person hasn't moved yet.

Some of those same facts aren't facts at all.

They're plans.

Possibilities.

Decisions.

That's the difference we care about.

The decision surface

We've started calling this the decision surface.

It isn't everything that matters to the analysis.

In April, that surface might be fairly large.

The move date may still be open.

The housing arrangements may still be open.

Future travel may still be open.

Future work location may still be open.

A planned transaction may not have occurred.

A compensation event may still be ahead.

By November, some of those possibilities have disappeared.

By February, many have become history.

That doesn't make February unimportant.

It makes it a different kind of problem.

And that's where we think a lot of software—and sometimes the way professional services are organized—misses something.

We are very good at systems that ask:

What happened?

We're less practiced at systems that ask:

What is still capable of happening differently?

The cleanest input may be the first mistake.

Software loves a clean field.

So our California-to-Brooklyn move becomes:

MOVE_DATE = 07/01/2026

Beautiful.

Now we can compute.

Except we've just taken months of human transition and compressed them into one date.

Maybe that's fine.

Sometimes it will be.

But before we collapse the information, shouldn't the system know whether doing so changes anything?

Because there may be a timeline underneath that date:

California residence.

Brooklyn residence.

Physical presence.

Spouse and household location.

Work location.

Employer location.

Compensation events.

Transactions.

Travel.

Evidence.

And those timelines don't necessarily move together.

The goal isn't to preserve complexity because complexity sounds sophisticated.

Quite the opposite.

Keep the complexity that can change the answer. Throw away the complexity that can't.

The difficult part is knowing which is which.

The Boolean is the problem

In software, a Boolean simply reduces something to two possible states: yes or no, true or false. That's incredibly useful—once the underlying question is actually ready for a yes-or-no answer.

Imagine our system eventually produces:

Nice.

Clean.

Machine-readable.

And potentially economically consequential.

So before we celebrate the beautifully structured data, there are a few questions worth asking.

Who turned it to TRUE?

When?

Based on which facts?

Under which residency test?

For which period?

What evidence supports it?

What evidence cuts against it?

Was anything important unknown?

Was the conclusion calculated?

Inferred?

Professionally determined?

Because if we get those questions wrong, making the field cleaner doesn't make the conclusion better.

It just makes the uncertainty harder to see.

That's the problem.

Not Boolean logic.

When we collapse reality into certainty too early.

Or, if you want the technical version:

premature state collapse.

Same problem.

Much worse name.

Sometimes “I don't know” is the intelligent answer.

Professional systems don't get this luxury very often.

Forms want completed fields.

Databases want values.

Users want answers.

AI models are especially good at giving them.

But imagine we ask our person:

What was your relationship to the California home after you began living in Brooklyn?

Maybe they know exactly.

Maybe their spouse was still there.

Maybe the property remained available.

Maybe they were going back and forth.

Maybe it was listed for sale.

Maybe the documents and the person's recollection don't line up perfectly.

Maybe we need more information.

A system that sees an empty field has a temptation:

Fill it.

A decision system should have another option.

UNKNOWN

Or:

NEEDS DOCUMENTATION

Or:

NEEDS PROFESSIONAL REVIEW

Those aren't failures to reach an answer.

Sometimes they're the most accurate description of the problem.

There's also an important difference between:

We don't know the fact.

We know the fact, but the governing rule is uncertain.

and

We know the facts and the rule, but applying them requires judgment.

Collapsing all three into something like:

72% CONFIDENT

doesn't tell the professional much.

Seventy-two percent confident in what?

The evidence?

The rule?

The interpretation?

The model?

A useful system should know what it's uncertain about.

Residency isn't sourcing.

This is where our seemingly simple move gets even more interesting.

Suppose California residency ends.

That doesn't automatically mean California disappears from every tax analysis.

Suppose New York residency begins.

That doesn't automatically answer how every dollar of income should be treated.

Residency asks one family of questions.

Sourcing asks another.

Compensation timing can ask another.

Evidence asks another.

And sometimes they overlap.

That's why we don't think a system should have one giant internal variable called:

TAX_STATE

It's too lossy.

A better system needs to be able to say:

Here's what we think about residency.

Here's what we think about this particular income item.

Here's the timeline underlying the compensation.

Here's the evidence supporting the facts.

Here's what remains unresolved.

Those analyses may eventually produce one tax return.

That doesn't mean they should begin as one question.

The system should know why it's asking you that.

Anyone who has completed a complicated financial questionnaire knows the feeling.

Page 14.

Question 63.

You're now being asked something oddly specific about a thing you didn't realize mattered.

And there is no explanation.

So you guess.

Or you pick the answer that seems closest.

Or you decide you'll come back later.

Then that answer quietly becomes an input somewhere downstream.

We think there's a better standard.

A decision system shouldn't ask every question it knows how to ask.

It should ask the next question that materially changes the problem.

Do you still have the California residence?

Why does that matter?

Where are you physically working?

Why does that matter?

Do you have equity compensation?

Why does that matter?

When does it vest?

Why does that matter?

And if your answer makes an entire branch irrelevant, stop asking questions from that branch.

The goal isn't a bigger intake form.

It's less questioning with more information gained from each answer.

And ideally, when someone asks:

“Why do you need to know this?”

the system can answer.

So what should AI actually do?

This is where our tax research became an AI question.

The fashionable question is:

How much of the professional can AI replace?

We're increasingly convinced that's the boring question.

A more useful one is:

Where should each kind of authority live?

Some things computers should be extremely good at.

Count days.

Compare dates.

Maintain timelines.

Track events.

Apply deterministic calculations when the applicable rule and required facts are established.

Change one scenario variable and recompute everything downstream that actually depends on it.

AI can help somewhere else.

Turn a messy client narrative into proposed structured facts.

Notice contradictions.

Identify information that's missing.

Find potentially relevant authority.

Explain why a question is being asked.

Summarize evidence for review.

Translate a complicated scenario difference into normal language.

But there are places where the machine should stop.

Ambiguous domicile.

Conflicting authority.

Material facts that contradict each other.

Complex compensation questions.

Rules the system doesn't support.

Situations where professional judgment determines the position.

That's not the point where the AI failed.

Knowing where its authority ends may be one of the most important things an intelligent system can do.

Now ask the interesting question.

Go back to April.

Our person is still in California.

Brooklyn is coming.

The job is coming.

Some future income event is expected.

But the move hasn't hardened into history yet.

We now have a baseline.

We know some things.

We don't know others.

Some things have already happened.

Some are planned.

Some are controllable.

Some aren't.

We have rules.

We have evidence.

We have uncertainty.

Now we can finally ask:

What changes if something changes?

What if the physical move occurs earlier?

What if it occurs later?

What if the California residence remains available longer than expected?

What if the work location changes?

What if the household moves at a different time?

What if a planned transaction occurs before or after a meaningful transition?

Which changes matter?

Which don't?

Which create a tax difference?

Which merely look like they should?

Which trigger another analysis entirely?

And which can't responsibly be answered without a professional?

This is where we draw the line between a calculator and Decision Intelligence.

A calculator can tell us:

Scenario A: $X

Scenario B: $Y

Useful.

But incomplete.

We want to know:

Why did it change?

Which variable caused the difference?

Which rules became relevant?

Which income items were affected?

Which material facts didn't change?

Where is the uncertainty?

What would have to be true for the result to hold?

And:

Is the variable that created the difference still something the person can actually decide?

That's the decision.

The preparer didn't fail. The calendar moved.

There's an easy but unfair conclusion hiding in all of this:

Tax professionals should have caught this earlier.

That's not our argument.

Imagine the preparer does everything correctly in February.

They reconstruct the timeline.

They ask the right questions.

They source the income correctly.

They consider the appropriate credits.

They document the position.

They prepare an excellent return.

But February still isn't April.

By the time the preparer sees the problem, some of the variables they are analyzing may have stopped being variables months ago.

That's not necessarily a preparation failure.

It's a timing problem.

And it raises a question we're much more interested in:

What would professional tax work look like if the consequential questions could surface while more of the answers were still decisions?

Not so software can make the decision.

So the human and the professional can see the decision before it disappears.

More data isn't automatically more intelligence.

There's a darker version of this architecture.

If residency depends partly on where people are, why not track everything?

GPS.

Credit-card transactions.

Flights.

Phone location.

Every document.

Every movement.

Build the perfect record.

Maybe.

But there's a difference between preserving evidence and feeding everything into the decision engine.

If the fact we need is:

Present in New York on June 12.

the active analysis may only need:

June 12 → New York → supported

But “supported” can't become a black box.

The underlying evidence may still matter—especially if the position is questioned years later.

So the better architecture isn't:

collect everything

or

delete everything after extraction.

It's:

Preserve what may be needed to defend the fact.

Preserve where the fact came from.

Protect the sensitive source evidence.

And expose only what the current analysis actually needs.

That's a very different idea from surveillance.

A decision system doesn't become more intelligent because it can see more of your life.

More context is not automatically more intelligence.

Sometimes it's just more data.

The audit trail may matter more than the answer.

Two years later, somebody asks:

Why did the system reach this conclusion?

There is one answer we don't think professional software should be allowed to give:

“Because the model said so.”

We should be able to reconstruct it.

What did we believe the facts were at the time?

What evidence supported them?

What rule version was used?

Which scenario was being evaluated?

Which parts were calculated?

Which parts were inferred?

Where did a professional review the analysis?

Did someone override a system conclusion?

Why?

Professional systems need more than correctness.

They need reconstructability.

Authority should leave a trail.

The answer probably isn't a bigger model.

Something funny happened as this project became more complicated.

The architecture became more modular.

Not less.

The intake system doesn't need to determine residency.

The issue-spotting system doesn't need to make the client's tax position.

The research system doesn't need to become the professional.

The contradiction detector doesn't need to decide which person is right.

The scenario engine shouldn't invent legal rules.

The explanation layer shouldn't quietly introduce new legal reasoning.

Different systems can do different jobs.

And professional judgment can remain exactly where professional judgment belongs.

Maybe the future of professional software isn't one giant model that knows everything.

Maybe it's carefully bounded intelligence that knows what it's allowed to know, what it's allowed to conclude, and when someone else needs to take over.

Where we're probably wrong

We started with a tax question.

The tax research complicated the systems model.

The systems model exposed questions the original tax research wasn't organized to answer.

Then independent verification challenged both.

Good.

That's exactly what we wanted.

Because state residency refuses to stay in one box.

There's law.

Arithmetic.

Evidence.

Chronology.

Intent.

Income.

Jurisdiction.

Human behavior.

There are facts we can verify.

Facts we have to weigh.

Events that are already history.

Decisions that remain open.

And moments when the correct answer is:

We don't know enough yet.

We aren't claiming to have solved state residency with AI.

We're asking something more fundamental.

What would a system have to understand before it was allowed to say that it had?

If you're a tax professional, tell us where this architecture misunderstands how residency and sourcing work when real clients walk through the door.

If you build AI or decision systems, tell us where we're preserving complexity that could safely disappear—or where we've simplified something that shouldn't be simplified.

And if you live somewhere between those worlds, we're particularly interested in the boundary.

What should be computed?

What should be inferred?

What should be questioned?

What should require authority?

Because the most dangerous decision system may not be the one that gets the arithmetic wrong.

It may be the one that gives a perfectly clean answer to a question it never fully understood.