ALICE scenario selection needs objective-and-constraint lineage
ALICE describes importing a P6 or Microsoft Project schedule or a BIM model, setting optimization goals and constraints, generating alternatives on a time-cost graph, and selecting or exporting a solution. The chosen scenario still needs a record that explains its inputs, trade-off, authority, schedule promotion, and later variance.
Editorial figure by Contractor Systems Index. Source context: ALICE Technologies official product record.
Freeze the input and objective before comparing scenarios
ALICE's current page describes schedule-based and model-based optioneering. For schedule inputs, it names Oracle Primavera P6 and Microsoft Project; for model-based work, it describes a 3D model, parameterized project data, and means-and-method recipes. A defensible scenario record should identify the project, input system, native file or extract, file hash where appropriate, schedule or model version, data date, baseline reference, calendars, status, import time, transformation warnings, and the person who accepted the input population. [1]
Record the optimization objective in measurable terms before the run. Name the targeted milestone, completion date, cost basis, resource goal, risk tolerance, scope boundary, units, time horizon, and priority among competing objectives. A label such as fastest or most efficient is too thin if the team cannot show the metric, denominator, constraint set, and business reason used when alternatives were generated.
Version constraints and the generated scenario set
Resource availability, crew calendars, production rates, sequence logic, access, work areas, procurement dates, design releases, permits, safety prerequisites, temporary works, contract milestones, and cost assumptions can all change the feasible set. Preserve each constraint's value, unit, source, effective period, owner, approval state, and uncertainty. Distinguish a hard boundary from a planning preference and a missing fact from a permissive assumption.
Every generated schedule should carry a run identifier, software and method version where available, input versions, objective, complete constraint snapshot, creation time, scenario label, duration, cost result, resource profile, excluded or infeasible conditions, warnings, and relationship to the baseline. Later reruns should append a new scenario set. Without that lineage, a point on a time-cost graph cannot be reproduced or compared fairly with an alternative generated from different inputs.
Document the trade-off and selection authority
ALICE says generated schedules can be compared on a time-cost graph and a solution can be selected, exported, or explored further. The selection record should state which alternatives were considered, what objective each met, which cost and duration definitions were used, what risks or constraints differentiated them, and why the chosen option was preferred. Retain rejected alternatives and dissent where material instead of preserving only the selected output. [1]
Name the roles that prepared, reviewed, recommended, and approved the choice and the authority each held. A planner may operate the tool while an owner, contractor, joint venture, designer, commercial lead, or authorized project board makes different decisions. Selection inside an optioneering product does not by itself revise the contract, authorize acceleration, change means and methods, release contingency, approve cost, or direct field work.
Promote the choice into the controlling schedule explicitly
The existing SYNCHRO analysis governs a 4D representation and warns that the displayed sequence is not automatically the controlling schedule. The Primavera Cloud analysis governs probabilistic forecast output and warns that simulation does not approve a completion date. ALICE optioneering creates a different decision: selection among generated feasible schedules under stated goals and constraints, followed by any export or promotion. Keep that choice linked to, but distinct from, both visualization and risk forecasting. [1]
If a selected option is adopted, record the authorized schedule revision, change or recovery basis, notice and approval requirements, native export, import validation, activity and logic differences, new baseline or update identifier, effective date, distribution, and field communication. Then compare later status, actual production, cost, constraint changes, and variance against the selected scenario. An option remains a planning artifact until the controlling process accepts it, and later performance remains evidence rather than proof that the original model was right or wrong in every respect.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Contractor Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.