A scheduler opens ALICE Technologies on a Tuesday morning with a 480-day baseline that the owner has already called too long, and by the afternoon coffee the platform has explored eleven thousand build scenarios and surfaced one that finishes in 411 days, a sixty-nine-day saving that would normally take a week of manual logic surgery to even attempt. The temptation is to take that scenario, publish it as the new baseline, and let it drive the work, because the platform optimized it and the math is sound. But the platform optimized the objective it was given, finish faster, and it did not know that the concrete sub has one crew committed elsewhere for three weeks in the spring, that the tower crane cannot serve two pours on the same shift, or that the owner promised the anchor tenant a topping-out date that the fast scenario quietly violates. ALICE is the generative-design engine applied to scheduling, and it produces candidates, not decisions. This lesson is about the discipline of treating those thousands of generated scenarios as a menu the scheduler selects from against constructability and stakeholder reality, verifying the chosen scenario before it ever drives the work, because the schedule is one of the project's five gates and a generated schedule that runs the job is a generated schedule that can run it into a wall.

ALICE Is the Generative-Design Engine Pointed at the Schedule

The program has named four engines: generative AI that drafts language and documents, computer vision that reads images and reality capture, predictive ML that forecasts from patterns, and generative design that explores a solution space against an objective and returns optimized candidates. ALICE Technologies is the fourth applied to the construction schedule. You give it the activities, durations, logic relationships, and resources (crews, cranes, formwork sets, cash) and an objective such as minimize duration or minimize peak crew, and it does not draft one schedule the way a planner does; it explores the combinatorial space of sequences, crew assignments, and resource allocations, running through thousands or tens of thousands of feasible permutations and returning the ones that score best. This is the same kind of engine as Autodesk Forma exploring massing options or Augmenta routing conduit and returning layouts roughly twenty-five percent faster with about fifteen percent less material waste: a search over a vast option space guided by an objective function. A planner builds one logic network; ALICE evaluates sequences a human could never enumerate, finding the non-obvious orderings, the parallel work the planner did not overlap, the crew flow that eliminates a bottleneck.

What makes this powerful is the same thing that makes it powerful for design: the space of possible build sequences is far too large for a human to search by hand. When a team reports that ALICE found a schedule twelve or fifteen percent shorter than their hand-built baseline, that is the engine surfacing the good option hidden in a space too large to search manually.

But naming it as the generative-design engine is a warning, not a label: the engine carries a known failure mode taught in the design lessons, and it travels into scheduling. The engine optimizes the objective function you state and is indifferent to everything you did not state, which is why an ALICE scenario is a candidate and not a plan.

The Objective-Function Problem Travels Into Scheduling

A generative-design engine optimizes exactly the objective it is given and treats everything outside it as free to sacrifice. In the design lessons this was a Forma massing that maximized floor area while quietly violating a setback, or an Augmenta conduit run that minimized material while routing through a beam it did not know was structural. The engine was not wrong; it optimized what it was told and ignored what it was not. ALICE has this exact property: tell it to minimize duration and it will compress the schedule by any feasible means within the model, and the means it chooses may trample constraints that live in the real world but not in the model.

Consider what typically lives outside the ALICE model. Real crew availability: the platform assumes it can staff the crews the scenario calls for, but the concrete sub may not be able to surge from two crews to four on the dates the fast scenario demands. Site logistics: the model may sequence two large pours in parallel without knowing that the single tower crane and pump cannot serve both on the same shift, or that the laydown yard cannot stage steel for three simultaneous erection fronts. Stakeholder commitments: the owner promised a topping-out ceremony, the tenant signed a lease tied to a substantial-completion date, the city permitted certain night-work windows, none in the resource model. Weather, procurement lead times, the inspector's availability, a crew's learning curve: the model holds what you put in it, and what you did not put in is exactly what the optimizer will sacrifice to hit the objective.

A generated schedule is the answer to the question you encoded, not the question you have. ALICE optimizes the objective in the model and is blind to every constraint outside it, so the fast scenario it returns is a candidate to be tested against reality, never a plan to be published.

This is why the engine produces candidates and not decisions, the same reason in scheduling as in design. It has done the part it is good at, searching an enormous space and returning high-scoring options. It cannot do the part that requires knowing the unstated reality: whether the high-scoring option is actually buildable by this team, on this site, against these commitments. That part is the scheduler's act of selection.

Scenarios Are Candidates, the Selection Is the Scheduler's Job

ALICE does not return one schedule; it returns a field of scenarios, each a different trade-off. One finishes fastest but needs four concrete crews at peak; one needs only two but runs forty days longer; one fast-tracks structure and skin in parallel but pushes crane utilization to the limit; one smooths the cash curve at a small duration cost. The platform presents these as a menu with their scores, and the menu itself is the useful product, because it shows the shape of the trade space: what a day of duration costs in crew or cash, where the cliffs are. But a menu is not a meal. The scheduler must select, and selection converts a candidate into a real plan.

This is the decide-then-draft principle the program has carried since the early lessons. The wrong order is draft-then-decide: let ALICE generate the fastest scenario, publish it, then discover the broken commitments when the crew does not show. The right order is decide-then-draft as selection: the scheduler decides which scenario reflects the real crew availability, site logistics, and commitments, and only that verified scenario becomes the baseline. Generation is cheap and exploratory; selection is the deliberate human act that carries the responsibility, because the selected scenario is what the trades are held to and what the owner is promised.

Selecting against constructability and stakeholder reality means the scheduler walks the candidate the way a senior planner walks any schedule, now with the trade space in front of them. Can the concrete sub actually staff this crew curve? Call and confirm before selecting, not after publishing. Does the crane plan hold? Lay the lift schedule over the pour sequence. Does the fast scenario keep the topping-out promise and the tenant date? Read its milestones against the commitments. The scheduler is not re-doing ALICE's search; they are testing its best candidates against the reality the model did not contain, choosing the one that survives, or sending ALICE back with a new constraint.

Verify Before the Schedule Drives the Work

The schedule is one of the program's five verification gates alongside design intent, code, contract authority, and life-safety, and it earns a gate because once published as the baseline it drives consequential action: it commits crews, triggers procurement releases, sets the pay-application earned-value curve, and becomes the document against which delay and disruption claims are argued. A flawed schedule does not stay a planning error; it propagates into a missed crew commitment, a stalled trade, a delayed milestone, and eventually a claim. The cardinal rule, verify before you stamp, schedule, pay, or plan for safety, names scheduling explicitly, so a generated scenario must clear the gate before it drives anything.

Verification here is consequence-proportioned: the depth of checking scales with what the artifact will do. A scenario only studied to understand the trade space needs little verification; one about to become the published baseline that commits the next ninety days of crew and procurement needs deep verification. A fast baseline that assumes crews the subs cannot supply will not just run long; it will run the trades into conflict, blow the procurement releases, and corrupt the earned-value baseline the pay applications and any future claim rest on.

This also surfaces the chained-workflow propagation the program warns about. The selected schedule does not sit alone; it feeds the look-ahead, the procurement release dates, the crew loading the subs plan to, the pay-application schedule of values, and the baseline a delay claim is measured by. An error propagates through every one, so verification at selection protects not one document but the chain. Catching a broken crew assumption at selection costs a phone call; catching it after it has driven a procurement release and a sub's mobilization costs real money and time.

The Asymmetry: A Fast Scenario That Quietly Breaks a Commitment

The program teaches false-negative asymmetry: the error that hides is worse than the one that announces itself, because the announced error gets caught and the hidden one drives the work. In scenario selection the dangerous error is the false negative: the scenario that looks clean, scores beautifully, and quietly violates a constraint the model did not hold. A scenario that obviously cannot work announces itself and gets rejected. The scenario that finishes sixty-nine days early by assuming a crew surge the sub cannot deliver looks like a triumph and gets published, and the violation only surfaces in the spring when the crew does not show, by which point procurement releases and owner promises are built on it.

This tells the scheduler where to spend verification attention: not on whether the fast scenario is impressive (the platform already confirmed that) but on hunting for the quiet constraint it might be violating. The posture is adversarial toward the attractive scenario, asking what unstated thing it is sacrificing to win, because the engine wins on the stated objective by spending the unstated constraints. The scheduler treats a scenario's score as a metric-as-signal: a strong score signals a candidate worth examining, not a plan worth publishing, and the stronger the score, the harder the scheduler looks for what it cost.

So the scheduler runs the selection like an investigator rather than a shopper: not picking the highest score and moving on, but probing the top candidates for the silent violation, converting hidden constraint violations into announced ones before publication. The scenario that drives the work is then one whose sacrifices the scheduler has seen and accepted, not one waiting in the spring.

The Scheduler Holds Responsible Charge of the Plan

The program borrows responsible charge from the engineering licensing world: a tool can produce, but a responsible professional owns the output and answers for it. ALICE can generate eleven thousand scenarios, but it cannot be in responsible charge of the schedule, because it cannot be called into the owner's meeting to defend the baseline, held to the crew commitments, or made to stand behind the date the tenant's lease depends on. The scheduler, or PM, holds that charge. The selected scenario is theirs the moment they publish it, and they answer for it as if they drew every line, because in the sense that matters they did.

This reframes the scheduler's job when ALICE is in the room. It is no longer the manual labor of building logic networks by hand. It is the judgment: defining the objective and constraints carefully enough that the search is useful, reading the trade space, selecting the scenario that survives contact with the real crews and site and commitments, verifying it against the schedule gate, and owning it. A scheduler who lets ALICE pick the baseline has abdicated responsible charge to a tool that cannot hold it; one who explores, then selects and verifies, has used the engine exactly right.

Holding responsible charge also means owning the feedback loop. When a crew curve that looked feasible turns out not to be, the scheduler does not blame the platform; they update the constraints and re-run, treating ALICE as an instrument they steer rather than an oracle they obey, so the next generation reflects what the last one missed.

The Applied Problem: A Scenario-Selection Protocol

Here is the exercise. Build the scenario-selection protocol your team will use whenever ALICE, or any generative scheduling engine, returns a field of candidates. Its purpose is to convert generated scenarios into a verified, owned baseline. Specify the objective and constraints you feed the engine, how you read the trade space, the selection test against constructability and stakeholder reality, the verification the selected scenario must clear before it drives the work, and who holds responsible charge of the baseline.

Produce two artifacts. First, the selection protocol: the inputs to the engine (activities, durations, logic, resources, the stated objective, and the constraints you can encode), the trade-space read, the selection test (explicit checks against real crew availability, site logistics, and stakeholder commitments the model does not hold), and the verification gate the selected scenario clears before publication. Second, the constraint-capture analysis: the constraints that typically live outside the model on your projects (crew availabilities, crane and laydown limits, owner and tenant and permit commitments) and, for each, how the scheduler tests the selected scenario against it, because these are the unstated constraints the optimizer will sacrifice and the scheduler must defend.

The lasting product is a team that uses ALICE for what it is, the generative-design engine that searches the schedule space better than any human, while keeping selection, verification, and responsible charge firmly with the professional. The scheduler who masters this gets the engine's enormous leverage without inheriting its blindness, because the protocol places human judgment exactly where the engine is blind: at the selection of the candidate that survives the real crews, site, and commitments, and at the verification before it drives work.

Key Takeaways

• ALICE Technologies is the generative-design engine (the fourth, alongside Autodesk Forma and Augmenta) applied to the schedule: it searches a vast space of sequences, crew assignments, and resource allocations against a stated objective and returns optimized candidates no human could enumerate by hand.
• The objective-function problem travels into scheduling: ALICE optimizes exactly the objective you state (minimize duration, minimize peak crew) and is indifferent to every constraint outside the model, so the fast scenario may quietly sacrifice constraints in the real world but not the resource model.
• The constraints outside the model are the ones the optimizer sacrifices: real crew availability (the sub cannot surge as assumed), site logistics (one crane and pump cannot serve two parallel pours), and stakeholder commitments (the topping-out promise, the tenant lease date, the permitted night-work windows).
• Scenarios are candidates, not decisions: ALICE returns a field of trade-offs, and the scheduler's selection against constructability and stakeholder reality converts a candidate into a baseline, decide-then-draft run as selection.
• The schedule is one of the five gates, so verify before it drives the work: a published baseline commits crews, triggers procurement, sets the earned-value curve, and anchors future claims, and verification is consequence-proportioned.
• The dangerous error is the false negative: the attractive scenario that scores beautifully while quietly violating an unstated constraint, so the scheduler treats the score as a metric-as-signal and probes the top candidates adversarially for the silent sacrifice.
• The selected schedule propagates through a chain (look-ahead, procurement releases, crew loading, pay-application schedule of values, claim baseline), so verification at selection protects the whole chain, and the gate is cheapest there.
• The scheduler (or PM) holds responsible charge of the published baseline: ALICE generates but cannot defend the schedule to the owner or stand behind the tenant date, so the human owns the selected scenario as if they drew it and steers the engine by updating constraints from field reality.