The Imputation step I applied does not drop any
missing values, instead it replaces the records
with adjacent values (assuming the observations
are based on the same individual). After the
imputation, there are 6 rows.

Since each of the columns are linearly
independent, I thought normalization
would not confound the regression
model. You are saying, without this
process step, given this knowledge,
I could generate a sensible model?

Here is a stack overflow answer that does a far better job than I could.

The short version is that an OLS regression really doesn’t care, you could multiply all your values by a billion but the coefficients would stay the same. You can also multiply a single column by any number and the T-stat will remain the same, the coefficient will be scaled by the inverse of what you multiplied it by.

What I took away from the Stack Overflow stream was
normalization can help with printability for presentations
but is not altogether necessary, especially on modern
machines that perform some standardization by design.

For a general decision-making reference, OLS is invariant
where normalization will not significantly influence coefficient
values. Alternatively, tests like Ridge or Lasso are variant, so
normalization is encouraged for those and similar test
conditions.

In response to

Can you try running this in a fresh environment

I restarted the Julia session, started a new
environment, did not normalize, and am
getting the same issue as above

DomainError with 0.0:
FDist: the condition ν2 > zero(ν2) is not satisfied.

The issue I identified prompted by
your response was that one should
not use too many predictors when
evaluating the ols. In my case the
original DF had 13 columns, and I
attempted to apply all of them to
the lm(@formula) instruction.

1000 is simply a scaling parameter. Since each
column in my df is linearly independent, it is less
presentable when I plot the outputs. The value
itself is arbitrary, but ultimately it is intended to
standardize the dataset across the attributes.

I think there’s no need to get personal here - I would tend to agree that it would be helpful for OP to consult some introductory statistics/econometrics textbooks to get a better understanding of the methodologies he’s using, but that’s not all that relevant to the concrete question at hand.

What I would humbly ask of you, @YummyPampers2, though is to be respectful of other people’s time and effort spent helping him. Practically this means reading Please read: make it easier to help you and following the advice given there, and in particular making sure that a question is backed up by an example which produces the actual error you’re seeing.

In this case four people have tried helping you with a problem that could not actually be reproduced from the code you posted, and only 24 hours and 17 posts into the thread did you reveal that actually you were running an entirely different regression on different data when you got the error you were asking about. In the event you were lucky that an econometrics professor from one of the leading departments in Europe was on hand to correctly guess what your problem is despite the inadequate MWE, but it’s easy to see how in a slightly different situation the wild goose chase could have gone on for quite some time.

For this thread, as I expressed, I used
too many attributes for the OLS in my
original formulation. I was able to
adapt what @mcreel had suggested
about degrees of freedom and sample
size, and reduce the dimensions used
to inform the OLS model.

FWIW I think this kind of error will be fixed by https://github.com/JuliaStats/GLM.jl/pull/458. Then you will get a coefficients table with infinite standard errors and confidence intervals and p-values equal to 1 for the problematic coefficients. Hopefully this will make it a bit easier to understand what is going on.