Summary
- AEC Software's practical value sits in the moment when an informal plan becomes an accepted schedule: dependencies, calendars, resources, baselines, file exchange and review habits must survive repeated changes, not merely produce an attractive timeline once.
- FastTrack Schedule looks strongest for teams that need a desktop-centered scheduling tool with lower ceremony than enterprise project systems, but its economics depend on update discipline, file ownership, training, and whether Microsoft Project, collaborative work platforms or disciplined spreadsheets are better substitutes.
The schedule change is the real trial
The easiest version of project scheduling is the first version. A manager collects a task list, estimates dates, draws a timeline, gives every phase a name, and circulates a PDF or slide. The room has not yet discovered the weak spots. Nobody has asked whether a delayed permit changes procurement. Nobody has noticed that the same supervisor has been assigned to two overlapping jobs. Nobody has changed the regional holiday calendar, split a task, added a resource, or asked why the critical path moved. A plan can look professional before it has done any operational work.
AEC Software's FastTrack Schedule should be judged from the next moment, when that first plan has to become an accepted schedule. The accepted schedule is different from an informal tracker because people begin to rely on it. A project manager uses it to explain why one activity must move before another. A team lead uses it to commit people. A client uses it to understand when a milestone will land. A finance or operations manager uses it to reason about time, cost and workload. The schedule is no longer decorative. It has become a record of decisions.
That is why the important question for AEC Software is not whether FastTrack Schedule can make a Gantt chart. It can. The more serious question is whether a FastTrack-style schedule can preserve dependency truth, calendar context, resource state and presentation clarity through repeated project updates. If it can, the product reduces supervision cost and gives smaller teams a manageable way to control work. If it cannot, it becomes a better-looking version of the same manual tracking problem.
The distinction matters because AEC Software occupies a particular space in project management software. It is not trying to be a broad corporate collaboration suite. It is not a construction megaproject control system with heavy contract administration. It is not simply a spreadsheet with bars drawn over dates. Its long-running product line is desktop project scheduling software for Windows and Mac users who need plans, dependencies, calendars, resources and reports without the full burden of a large enterprise platform.
That position can be valuable, especially for small businesses, construction and engineering teams, operations planners and project managers who repeatedly turn informal plans into schedules accepted by other people.
But the position also creates a narrow performance test. A desktop schedule can be fast to start and easy to present, yet still fail if the next change breaks the logic, if exported files lose meaning, if calendar differences are misunderstood, if resource loading becomes a fiction, or if stakeholders stop treating the file as the shared record. The accepted schedule change exposes all of those weaknesses.
What AEC Software is actually selling
AEC Software presents FastTrack Schedule as project management software for planning, tracking and reporting projects on Windows and Mac. The current public product pages describe FastTrack Schedule 2026 for Windows and Mac, while the support center also contains detailed FastTrack Schedule 2024 maintenance and platform information. The product boundary is clear enough: this is AEC's scheduling and project-planning line, not the broader architecture, engineering and construction industry acronym, not Microsoft Project, and not a customer's governance process.
The official product pages emphasize Gantt charts, dependencies, resource assignment, budgets, reports, critical path, PDF output, Microsoft Project import/export, Excel and CSV exchange, calendar import, and Mac/Windows file sharing. The Mac page adds the familiar macOS layer: native application behavior, Apple Silicon support, Retina display, iCloud document handling, Finder Tags and Dark Mode. The Windows page frames the product around a ribbon-style desktop scheduling experience, one-click reports, PDF export, Microsoft Project XML exchange and system requirements that include Windows 11, Windows 10 and ARM64 support.
Those features are not unusual in the project scheduling category. The point is how they come together for a team that is moving from informal tracking into an accepted plan. An informal tracker can live in a spreadsheet, a to-do app, a whiteboard or a shared notes document. It becomes fragile when people need to know how one date change affects the rest of the work. FastTrack Schedule's value proposition is that the schedule can hold more structure than the informal tracker while remaining lighter than enterprise systems whose setup, administration and training cost may exceed the value of the project being managed.
That is a commercial argument as much as a technical one. A project manager does not buy scheduling software only to draw bars. The buyer is paying to reduce the cost of repeated coordination. If a project plan is revised once, manual effort may be tolerable. If it is revised every week, manual effort becomes a tax. If a resource change must be explained to a contractor, a client, a department head and a finance owner, the schedule has to serve different readers without being rebuilt for each meeting.
If a project has dependencies, calendars and resource constraints, the accepted schedule must make those constraints visible enough that people trust the update.
FastTrack Schedule appears designed for exactly that middle zone. It gives the project manager a structured schedule file with views, dependencies, resource context and reporting, but it still speaks the language of desktop documents: files, exports, print-ready schedules, PDF output and cross-platform handoff. That makes it approachable. It also means file ownership and update discipline remain central. Unlike a fully centralized collaborative system, the accepted record can still become unclear if copies circulate, if exports become treated as live schedules, or if team members do not know which file contains the current plan.
Why the first accepted change matters
The accepted schedule change is the moment when the product's useful machinery either appears or disappears. Suppose a construction coordinator has moved a project from email notes and a rough spreadsheet into FastTrack Schedule. The initial plan includes site preparation, inspections, procurement, subcontractor work, internal review, client sign-off and final handover. The first schedule is approved because it is clear. Then a key inspection moves by five business days. The coordinator now needs to adjust the plan without lying to the rest of the schedule.
A weak tool lets the coordinator drag a bar and move on. A stronger scheduling tool reveals what changed. Which downstream tasks depend on the inspection? Which resource assignments now overlap? Does the delay cross a non-working day or holiday? Does the baseline still show the original commitment? Does the revised plan show the difference between planned and actual progress? Can the coordinator send the client a clean report without making a second manual version? Can another manager with Microsoft Project receive enough of the schedule to understand the change? These are not edge cases. They are the everyday life of an accepted schedule.
This is where FastTrack Schedule's public evidence becomes relevant. AEC describes dependencies, critical path, baselines, revised dates, actual dates, resource details, reports, filters, calendar views and Microsoft Project exchange. The older detailed manuals and current training pages show that AEC has treated these as real scheduling concepts, not just labels in a feature grid. The support material also acknowledges that data can become unhealthy when pasted from old files, other applications or corrupted clipboard contents, and points users to a Check Data function that parses and attempts to repair file data.
That support article is important because it recognizes the darker side of schedule maintenance: the schedule file is an operating record, and operating records can be damaged by everyday handling.
For the buyer, this creates a useful but sober view. FastTrack Schedule provides the components needed to manage the accepted schedule change. It does not remove the need for schedule discipline. A dependency that was never entered cannot be preserved. A resource calendar that was never configured cannot warn the manager about overload. A baseline that was never saved cannot show variance. A PDF sent to a stakeholder cannot update itself. A Microsoft Project file opened from another organization may not preserve every nuance, especially where the vendor itself uses careful wording such as "most" files.
The software can carry schedule truth only to the extent that the team captures that truth in the first place.
Dependency truth is the core
The accepted schedule is only as honest as its dependencies. A date bar without dependencies is a picture. It may be useful for presentation, but it does not explain cause and effect. When the predecessor slips, a successor should not remain in place merely because the drawing still looks tidy. The point of a scheduling tool is to encode enough logic that the project manager can see consequences before they become surprises.
AEC's public materials put dependencies near the center of the product. The product pages describe Gantt timelines with tasks, milestones and dependencies. The training syllabus includes tracking with dependencies. The manual describes linked bars and the ability to see how changing one bar affects the final outcome of the schedule. AEC's own educational blog describes several methods for defining dependencies: drawing a link between bars, entering predecessor or successor rows, or selecting a group of rows and using a link tool to define links in sequence.
That range of methods matters because dependency entry is a supervision cost. If a manager has to create every dependency one by one, a larger schedule becomes slow to build and easy to leave incomplete. If the tool helps create sequential links across selected rows, it reduces the friction of building a schedule that actually has logic. But faster entry is not the same as correct logic. A chain of links can still encode the wrong relationship. A finish-to-start assumption may be too simple. A task might have lead or lag. A dependency might be external to the team and therefore harder to update.
If the schedule is accepted by stakeholders, those details become commitments.
The failure mode is familiar. A team begins with a visually impressive plan. Then changes arrive, and the project manager starts dragging bars manually because the dependency network is incomplete or wrong. After a few rounds, the schedule no longer explains the work. It becomes an edited artifact. The manager may still be able to print a professional report, but the report is detached from project mechanics. That is the moment when the cost of the tool is hard to defend.
FastTrack Schedule's advantage is that it gives a smaller team enough dependency machinery to avoid that fate if the team uses it carefully. Its risk is that ease of drawing can encourage shallow scheduling. The product's best fit is therefore not the team that wants a pretty Gantt chart for one meeting. It is the team that can name real predecessors, update them consistently and use the schedule as a living decision record.
Calendars and resources decide whether the schedule is believable
Dates do not exist in isolation. A project plan has calendars, non-working days, regional holidays, shifts, team availability, subcontractor windows and resource constraints. A plan that ignores these details may still be clear, but it will not be believable after the first accepted change. If a schedule moves across a holiday, the elapsed calendar time and the working time may diverge. If a resource is assigned to two critical tasks at once, the plan may be mathematically neat and operationally false.
FastTrack Schedule's evidence here is stronger than a simple feature list. AEC's product pages refer to resource assignment, workload balancing, budgets, resource cost and work details, dynamic resource filters, color calendars and .ics calendar import. The Mac page describes Schedule, Resource and Calendar views. The older manual explains that the Resource View lets a user track which tasks resources are assigned to, what percentage of available time is being used, and how many hours are being worked in a period. The tutorial material goes further into work calendars, non-work days, work hours and day-of-week schedules.
This is the difference between schedule visualization and project control. A timeline tells people when things are supposed to happen. A resource-aware schedule tells the manager whether those dates can be staffed. A calendar-aware schedule tells the manager whether the dates mean the same thing across working patterns. A budget-aware or cost-aware schedule helps connect time to money. When a project manager updates an accepted plan, these connections are what prevent a change from being misleading.
The supervision cost is real. Someone has to define resources. Someone has to decide whether the resource is a person, a role, a crew, equipment, a vendor or a budget category. Someone has to maintain calendars. Someone has to adjust actual progress and percent complete. If the team does not do this work, the resource and calendar features become decoration. If the team does it, the schedule can answer better questions: not only "when does the task end?" but "who is overloaded, what changed from the original commitment, and which dates are at risk?"
FastTrack Schedule appears well suited to teams that need that second level of control but are not ready for a heavier platform. It gives them a visible schedule surface and enough underlying structure to discuss resources and calendars. It may be less suited to organizations that need always-on multi-user control, deeply governed permissions, enterprise portfolio reporting, or integrated financial systems. Those organizations may still use FastTrack in pockets, but the accepted schedule of record may need to live somewhere more centralized.
Baselines make change visible
The accepted schedule change is impossible to judge without a baseline. A revised date is not meaningful unless someone can compare it with the commitment that was accepted earlier. A project manager who simply overwrites dates can keep the chart current, but the team loses the story of the change. Was the project always going to finish in October, or did October become the finish after procurement slipped? Did the contractor recover two weeks, or was that recovery only created by moving a downstream task out of scope? Without a baseline, nobody can tell.
AEC's training syllabus explicitly includes baselines and progress tracking, revised dates, percent complete, actual dates, status columns and tracking with dependencies. The product materials also describe multiple baselines and enhanced progress tracking in current or recent versions. That is the right evidence for the accepted schedule angle. Baselines are not a premium decoration. They are the minimum structure that lets a schedule remain accountable after the first change.
A useful accepted schedule therefore needs at least three layers of time. The first is the original or approved plan. The second is the current revised plan. The third is actual progress. If the tool can show all three without forcing the manager to build a manual comparison in a separate spreadsheet, it reduces the cost of supervision. The manager can explain variance, not merely announce a new date. The stakeholder can see whether a change is a delay, a recovery or a redefinition of scope.
The risk is that baselines can become ceremonial. A team may save a baseline once and never maintain change reasons. A manager may update the plan without recording why. A client may receive a report that shows planned and revised dates but not enough context to understand the decision. FastTrack Schedule can give the structure, but it cannot supply governance by itself. The team still needs a habit: save the accepted baseline, mark actuals, revise dates deliberately, and treat major changes as decisions rather than mouse movements.
That habit is where a desktop scheduling product can either be liberating or fragile. It is liberating because a competent manager can update the schedule quickly, generate a report and avoid the overhead of a large system. It is fragile because much of the control rests with that manager's discipline. If the manager leaves, if copies diverge, or if the schedule owner stops updating progress, the accepted schedule loses authority.
File exchange is valuable, but it is not the same as shared truth
AEC's file-exchange claims are commercially important. Many teams do not choose scheduling software in isolation. They inherit Microsoft Project files from partners, use Excel lists internally, share PDFs with clients, export images for presentations, and send updates to people who do not own the same application. A tool that cannot exchange data becomes a silo. A tool that exchanges data badly becomes a risk.
FastTrack Schedule's public pages highlight Microsoft Project XML import/export, Excel and CSV exchange, PDF and image export, clipboard copy, Mac/Windows file sharing and .ics calendar import. AEC's support center says FastTrack Schedule 2024 can directly open and modify most Microsoft Project 2019, 2021 and 2024 .mpp and .xml files. The use of "most" is important. It is not a promise that every field, calendar, constraint, resource assignment, baseline or custom behavior will survive every round trip. It is a practical compatibility claim with a boundary.
For the accepted schedule change, this boundary matters. If a team imports a Microsoft Project file, revises it in FastTrack, exports it back, and a stakeholder then opens it in Microsoft Project, the crucial question is not whether a file opens. The question is whether the schedule still means the same thing. Are dependencies preserved? Are calendars preserved? Are resource assignments preserved? Are manually scheduled tasks interpreted correctly? Are baseline dates and revised dates still clear? Are custom fields lost? Does the critical path still explain the same risk?
The article's judgment has to stay cautious because public evidence does not prove those round trips. It shows that AEC supports exchange paths and has invested in compatibility. It does not prove reliability for every complex partner file. For simple and moderately structured schedules, exchange may be enough to reduce switching cost and stakeholder friction. For heavily governed Microsoft Project environments, the only responsible answer is to test representative files before making FastTrack the accepted schedule record.
PDF and image export are different. They are not intended to preserve schedule logic. They are communication outputs. They matter because stakeholders often approve what they can read, not what the scheduling engine knows. FastTrack's presentation strength is useful if the manager can generate a clear report for a meeting without rebuilding the schedule in slides. But once a PDF is distributed, it should be treated as a snapshot. If recipients act as though the PDF is the live plan, file exchange has created a new failure mode.
The supervision cost is the hidden price
FastTrack Schedule's license price is only part of the economics. AEC's store and pricing pages show purchase and upgrade pricing, while education pages and concurrent-user pages show that pricing varies by license type and customer class. But the larger cost is supervision. A project schedule has to be built, checked, updated, shared and defended. The more trusted the schedule becomes, the more expensive errors become.
For a small team, the economic case is straightforward. If FastTrack Schedule lets a project manager turn repeated planning sessions into a maintained schedule, avoids spreadsheet confusion, reduces meeting time, produces client-ready reports, and prevents even a few avoidable resource conflicts, the software can pay for itself. The license cost is modest compared with the cost of a missed crew date, a delayed delivery, a manager spending hours rebuilding charts, or a client losing confidence because every meeting shows a different version of the plan.
But if the product is used only as a prettier drawing tool, the economics weaken. A spreadsheet, a general task board, a presentation slide or a lightweight online project app may be enough for a team with low dependency complexity. The added cost of learning baselines, resources, calendars and exports may not be justified if the schedule is rarely updated or if no stakeholder relies on it. The value appears when the plan changes often enough that manual coordination becomes risky.
Training is part of the calculation. AEC offers training material and documentation, and older independent reviews have praised tutorials and templates. That is encouraging because many users arrive as accidental project managers. They know the work but not formal scheduling. A tool that can teach them enough to create dependencies, calendars, baselines and reports has value beyond features. Yet training also reveals the adoption burden. If a team refuses to learn the scheduling concepts, the tool cannot make the plan trustworthy by itself.
There is also a support and maintenance cost. Desktop software must keep pace with operating-system changes. AEC's support pages show active attention to Windows, macOS and Apple Silicon compatibility, and they discuss current builds and bug fixes. That is a positive signal. At the same time, desktop scheduling depends on local installation, file handling, license management and user machines. A cloud-native tool shifts some of that burden elsewhere; a desktop tool gives the user more file control but keeps local lifecycle management in view.
Failure modes are ordinary, not exotic
The accepted schedule fails in ordinary ways. The plan becomes stale because nobody updates actual progress. A dependency is missing, so a downstream task does not move. A resource is overbooked because assignments were entered as labels rather than real capacity. A calendar mismatch makes two teams interpret the same finish date differently. A file copy circulates after the accepted version has changed. A PDF snapshot is mistaken for the current plan. A Microsoft Project export loses a nuance. A manager pastes data from an old file and introduces bad content. A stakeholder never adopts the schedule and keeps running work from email.
AEC's own materials map to many of these risks. Dependencies and critical path address broken cause and effect. Resource View and dynamic resource filters address workload visibility. Work calendars and .ics import address date context. Baselines, revised dates and actual dates address change accountability. Check Data addresses file-integrity problems. Microsoft Project exchange addresses external coordination. Reports and print output address stakeholder communication.
The presence of features does not eliminate the risks. It only gives the project manager tools to manage them. The most important failure mode is stale trust. A schedule can remain visually polished after it stops being true. Stakeholders may continue to read it because it looks official. That is worse than an obvious spreadsheet mess because the appearance of control hides the loss of control. The accepted schedule should therefore be reviewed not only for layout but for evidence that the schedule owner is maintaining the logic.
One practical test is simple. After an accepted change, ask what moved automatically, what moved manually, what resource became overloaded, what calendar rule mattered, what variance from baseline is now visible, what export was sent, and who confirmed that the update is the accepted record. If the team cannot answer, the software is not yet producing project control. It is producing project presentation.
This is also why the Capterra evidence, although too small to carry heavy weight, is worth noting. The visible review set includes positive comments about templates, resource availability and exports, but also a complaint about crashes tied to dependency history and consolidated schedule views. That does not prove a current defect in the latest build. It does illustrate the exact category of risk that matters: as schedules become more dependent and consolidated, reliability becomes more important than first-use convenience.
Where FastTrack fits among substitutes
FastTrack Schedule's substitutes fall into four groups. The first is the spreadsheet. Spreadsheets are cheap, familiar and flexible. They are hard to beat for a quick task list or a simple one-off plan. Their weakness is schedule logic. Dependencies, calendars, baselines, resource loading and critical path can be modeled, but the model is usually hand-built and fragile. When an accepted schedule changes repeatedly, the spreadsheet often becomes a negotiation over cells rather than a dependable project record.
The second substitute is Microsoft Project. Microsoft's project tools have deep scheduling concepts, broad enterprise recognition and a strong position with teams that already exchange .mpp files. For organizations that need Microsoft Project compatibility as the central requirement, FastTrack's ability to open and export Microsoft Project formats lowers friction but may not replace the need for Microsoft Project itself. The choice depends on user base and schedule complexity. If most stakeholders live in Microsoft Project, using FastTrack as the central accepted schedule may add round-trip risk.
If only occasional Microsoft Project exchange is needed, FastTrack may give a friendlier scheduling surface at lower operational burden.
The third substitute is the modern collaborative work platform: Asana, monday.com, Jira-like planning boards, ClickUp-style work hubs and similar tools. These products excel when task ownership, comments, notifications and team collaboration matter more than formal scheduling depth. Many now include timeline, dependency and Gantt-like views. Their advantage is shared access and live collaboration. Their weakness, for some users, is that they can blur the accepted schedule into a stream of tasks, comments and status fields. A project manager who needs a disciplined, presentation-ready schedule file may prefer FastTrack.
A team that needs every assignee to update tasks in a shared online space may prefer the collaborative platform.
The fourth substitute is a specialized industry scheduling system. Construction, engineering, professional services and operations teams may need systems with contract controls, field reporting, procurement links, budget integration, earned-value methods or portfolio governance. FastTrack Schedule is not positioned as that heavy system. Its value is the lighter middle: enough scheduling structure for serious project control, enough usability for a non-specialist, and enough document-style output for recurring stakeholder review.
This middle position is commercially attractive but defensible only if the customer has the right problem. AEC Software should not be bought because a team wants a Gantt chart. It should be bought because the team has recurring schedule changes that need dependency logic, resource context, baseline accountability and readable communication without enterprise overhead.
The customer-result boundary
The public evidence supports feature availability and product positioning. It does not prove customer results. AEC says FastTrack Schedule helps teams plan, track and report projects. Support pages show platform maintenance, current builds and compatibility claims. Training and manuals show that the product contains real scheduling mechanics. Review pages and older trade coverage support the idea that the product has historically been approachable and useful for smaller teams. None of that proves that a particular customer will reduce planning overhead, prevent delays, avoid resource conflicts or improve project margins.
That boundary is important because scheduling software often receives credit for discipline that belongs to the team. A well-run team can create a useful schedule in a modest tool. A poorly run team can corrupt a powerful system. FastTrack Schedule can reduce friction, make changes visible, improve presentation and hold scheduling logic, but it cannot decide task truth, enforce stakeholder adoption or guarantee that resources are honestly available.
The best customer-result claim is therefore conditional. If a team has repeated projects, enough dependency complexity to make spreadsheets risky, enough schedule review pressure to make presentation matter, and a schedule owner willing to maintain calendars, resources and baselines, FastTrack Schedule can plausibly reduce coordination cost. If the team lacks those conditions, the tool may be underused.
This conditional view is more useful than a simple recommendation. Project managers do not need another software slogan. They need to know whether the next accepted schedule change will become easier. AEC Software's product can help when the schedule owner uses the structured parts of the tool. It cannot rescue a plan whose logic remains informal.
A practical buyer test
Before buying or standardizing on FastTrack Schedule, a team should test its own accepted schedule change. The test should use a real project template, not a vendor sample. It should include a baseline, dependencies, at least one non-working day or imported calendar item, named resources or resource groups, a budget or cost field if cost is part of review, a stakeholder report and at least one external exchange format.
Then the team should introduce the kind of change that normally causes trouble. Move a predecessor. Change a resource. Add a holiday. Split a task. Mark partial actual progress. Export to PDF. Export to Microsoft Project XML if external coordination matters. Reopen the file on the other operating system if mixed Mac/Windows work matters. Ask a second user to interpret the report without explanation. The product passes only if the revised plan is not merely pretty but explainable.
The most important output of that test is not a yes-or-no feature checklist. It is a labor estimate. How long did the update take? Which step required specialist knowledge? Which field confused the schedule owner? Which export lost context? Which stakeholder still asked for a spreadsheet? Which part of the schedule became more trusted than before? That labor estimate tells the buyer whether clearer schedules and lower planning overhead exceed license cost, training, manual updating, file coordination and switching cost.
FastTrack Schedule's likely strength in this test is speed to a readable schedule. Its risk is the same as any document-centered scheduling tool: the accepted record depends on a disciplined owner and careful file handling. The product can make a project manager more effective, but it does not convert a group of passive stakeholders into schedule entities. It can expose dependency consequences, but only if dependencies exist. It can show resource views, but only if resources are maintained. It can export and import, but only testing can prove whether exchanged files preserve enough meaning for the customer's use.
Judgment
AEC Software matters because many teams do not need a massive project-control platform, but they do need more than a task list. They need a schedule that can be accepted, revised, reviewed and trusted. FastTrack Schedule sits in that practical gap. Its public materials show a product with the right conceptual pieces: dependencies, calendars, resources, baselines, critical path, reports, file exchange, platform support and training material. That makes it a credible candidate for project managers who repeatedly move informal plans into accepted schedules.
The caution is that every important benefit arrives after adoption discipline. The product's value is not the first Gantt chart. It is the second, third and fourth update, when the schedule still explains cause and effect. It is the moment when a manager can show what changed from baseline, why a date moved, which resource is constrained, and what the stakeholder is approving now. If FastTrack Schedule is used that way, its lighter desktop model can be a strength. It gives teams control without forcing them into a larger system than their projects justify.
If it is used as presentation software, the value fades. A good-looking schedule that is manually adjusted, poorly linked, weakly resourced and distributed in uncontrolled copies is not an accepted schedule. It is a polished risk. AEC Software's buyer should therefore make the purchase decision around the accepted schedule change. Can the team preserve dependencies, calendars and resource state well enough for repeated project updates? Can the schedule owner maintain the plan without excessive supervision cost? Can stakeholders trust the exported view without confusing it for the live file?
Can substitutes do the same job with less burden?
For teams in AEC Software's natural market, especially project managers, construction and engineering coordinators, operations planners, small businesses and desktop-centered teams, the answer may be yes. FastTrack Schedule has enough scheduling depth to be more than a drawing tool and enough usability to avoid the weight of a larger platform. But the software earns that answer only when a changed schedule remains a truthful schedule.