Why this exists

The schedule came back. Again.

Not because the plan was wrong. Because the file broke a rule in a specification section nobody had read closely enough — and the week stopped being about the building.

3engineers
50+years between us
7owners’ rules, read line by line

We are three engineers. Between us we have spent more than fifty years planning, updating and defending construction schedules — and a good share of that on the receiving end of a review comment that had nothing to do with how the building gets built.

Everyone who has submitted to a public owner knows the week. You build the plan, you cost-load it, you tie the logic, you submit. Then it comes back. Durations too long. A constraint that is not allowed. Activity codes missing from rows nobody thought were activities. A calendar that does not match the contract. An export that the receiving system simply refuses, with an error message that names a column number.

None of it is about the building. All of it is about whether the document obeys a section of the specification. And every time, the same two things were true: the payment slipped, and the finding had been sitting in the file the whole time.

The specification is published. The rules are written down. The durations, the open ends, the constraint types, the calendar assignments — all of it is already inside the file you are about to send. Every one of those comments could have been read out of it a week earlier, by anyone with the section open beside the schedule.

We spent years being the people who did that reading, by hand, at eleven at night, before a submittal. So the question stopped being why it kept happening and became why nobody had automated it.

The tools existed. They were checking the wrong thing.

Schedule checkers check best practice. They run the DCMA 14-point assessment, or something like it: a generic public checklist, the same fourteen questions for every project in the country. It is a genuinely useful health check and it is not your contract. It does not know which owner you are submitting to, which section they cite, or what that section says.

Your contract does not name best practice. It names a section number. That section is what the reviewer opens.

The difference, in one rule

Same activity. Two thresholds. One of them is in your contract.

A single non-procurement activity, 28 working days long. The generic checklist and the specification disagree about it, and only one of them is what you signed.

DCMA 14-point · generic

44
days before it is flagged

A public checklist, the same for every project. It also tolerates 5% of activities above the limit before the check fails at all.

USACE UFGS 01 32 01.00 10 Project Schedule · your contract

20
days, and no tolerance

“Non-procurement activities Original Durations (OD) are not to exceed 20 workdays or 30 calendar days.”

Pass the generic checklist and you can still be returned. That gap is the whole product. And it is not one threshold — it is 170 rules across 7 owners, each read out of the section that owner actually publishes.

What you get

The section your contract names. The edition in force. The sentence beside the finding.

Your report is written against the specification your contract cites — not against a generic checklist, and not against the owner next door. Seven owners are read separately because they ask for different things in different words with different consequences, and a schedule that satisfies one gets returned by another.

Every finding carries the specification’s own sentence. Not a paraphrase. You can put the report beside the section and see that they match, which is the only reason a compliance finding is worth anything. Editions are re-checked every quarter, because a threshold that moved while nobody was looking is how a compliant schedule gets returned.

And where the specification hands the decision to a person — where it says the cost loading must be reasonable, or the lag is as determined by the Government — we do not decide for you. The report draws the evidence, names the paragraph that hands the decision over, and leaves it with you and your Contracting Officer. That restraint is the difference between a tool you can put in front of an owner and one you cannot.

Where the line is

Four things this will never do.

A compliance tool earns trust by what it refuses to say. These are enforced in the code and in the tests, not in a policy document.

WILL NOT

Tell you that you are approved

No automated check can, and in several US states offering an engineering opinion without a license is an offense. This compares your file against published rules and hands you the findings. The submittal decision belongs to your Contracting Officer, on the whole submission.

WILL NOT

Invent a requirement

Every finding cites its section and carries the specification’s own sentence. A rule without a verified quotation is blocked from reaching you. Three invented passages once reached a draft of this website; a test now requires every quotation on the site to be some profile’s verbatim text.

WILL NOT

Call a judgment call a rejection

One wrong you will be rejected costs more than ten findings missed. Where a section says reasonable, or subject to approval, or as determined by the Government, the finding is marked for your decision and never as blocking. A test enforces it mechanically, rule by rule.

WILL NOT

Hide what it did not check

Meetings, narratives, contractual rights and companion documents cannot be evidenced by a schedule file. Every report ends with those requirements listed by paragraph number, so the coverage claim can be audited rather than believed.

What we have proved, and what we have not

The honest state of the evidence.

Most products in this category tell you what they can do. This is the other half, published because you are about to trust a report about your own submittal and you should know where it stops.

Verified against a real federal file

The export simulation

The fixed-column export USACE requires is validated against a genuine federal export published by the Corps itself — 2,722 activities, data date 31 March 2003. All fifteen column boundaries land correctly on it and not one value splits. That file also corrected four of our own assumptions, which is why it was worth finding.

Not yet proved on a real federal schedule

The logic, float, calendar and duration checks

These run correctly on real commercial schedules and on the fixtures, and they have not yet been run against a submitted federal schedule — because a submitted schedule is the contractor’s property and nobody has handed us one. If you send yours back with what it got wrong, that is the evidence this half is waiting on.

Outside any specification

What the receiving system enforces

The government’s own management system refuses an update whose actual dates disagree with the Daily QC Reports, and no paragraph of any specification mentions it. It is very likely a more common cause of rejection than anything in the rule set, and it cannot be seen in a schedule file. Every report prints it as context rather than pretending the file could answer it.

Who is behind it

Three engineers who got tired of finding out too late.

Three engineers, more than fifty years of schedules between us, and no sales team. There is no call to book and no seat license — you upload a file, you get a report, and the first one costs nothing.

That shape is deliberate. A small team cannot afford to be wrong in public, which is why every finding is quoted rather than summarized, why the gaps above are on this page instead of in a footnote, and why the whole thing is built to be checked by the person reading it.

We built this for the version of ourselves who used to do it by hand the night before a submittal. If a rule here disagrees with your contract, your contract wins — and telling us is the fastest way this gets better.

Standing commitment

Every finding carries the sentence it rests on, or it is not published.

170 rules · 7 owners
Editions re-checked quarterly

--:--:-- LOCAL
SCHEDULE COMPLIANCE · 7 OWNERS
0 × 0  X000 Y000