Files, import & output

The .ammg schedule file#

A schedule is the one artefact a scheduler will not risk, so the on-disk form is a real database file rather than a re-serialised blob. Rows and columns are real tables, which is what keeps a partial load possible later. The schema is owned by the native layer; cell contents are never parsed there.

What is in it, and what is not#

What is written is what a person authored. Dates, float and criticality are recomputed on load and never stored. A file carrying stale computed dates would show one answer on open and a different one the moment anything changed.

Alongside the sheet, the file carries history and comments — beside the sheet rather than inside it, because both are about the schedule rather than part of it, and a log growing inside the sheet would be re-parsed and re-diffed on every keystroke for the benefit of one panel.

⚠ History is appended on save; comments are replaced. The difference is the whole reason they are not one mechanism. A history entry is an immutable fact. A comment is mutable — it can be edited, resolved, reacted to and tombstoned — and treating it as append-only would make the first version of every comment permanent: an edit would appear to work until the file was reopened, and a resolved thread would come back unresolved.

⚠ A deleted comment is still written, as a tombstone. Dropping it on save would let somebody remove their own words from an audit by deleting and saving.

Opening a newer file#

The schema version is bumped whenever the shape changes in a way an older build cannot read. Adding an optional field is not a bump; removing or re-meaning one is — and so is adding anything an older build would either refuse outright or silently discard on the next save.

⚠⚠ A file from a newer build is refused, not half-read. The message names both versions and says to update. Opening a newer file with an older build and silently dropping the fields it did not understand is how a schedule loses its constraints and nobody notices until the dates move.

Going the other way, an older file opens and gains what it was missing: system columns are reconciled on open, additively, leaving the file's own column order, widths and visibility untouched. Without that, a capability added in one release would never reach a schedule written by the previous one.

Delimited-text import#

CSV and TSV, through a column mapper with type inference and a preview.

Hierarchy is detected from leading indentation, from a WBS-code column, or from a nominated outline-level column.

⚠ The inference is a proposal, never a decision. Sequence says what it thinks each column is, and you may overrule every entry before the import runs. An importer that guesses silently is one that puts a Cost column into Duration on a Tuesday and nobody notices until the dates move.

The fidelity report#

Import produces a report of what came across, what was approximated, and what has no equivalent — shown before the import commits, and saved with the sheet.

Anything not carried across verbatim must state what happened and why.

This is not a log. It is the difference between a scheduler trusting an imported schedule and re-checking a thousand rows by hand, and it is the only honest way to import a format richer than ours. An importer that silently drops what it did not understand produces a schedule that looks complete and schedules differently from the file it came from.

Plot output#

A schedule leaves Sequence as a drawn plot: PDF, PNG or SVG. PDF is the deliverable — it is what a monthly pack and a contractual submission actually are; SVG is the drop-into-a-deck path.

The renderer is deliberately primitive — rectangles, lines, polygons, a circle and text — so that adding a backend is a new file rather than a dependency negotiation.

What is plotted is decided by an output template, not by the screen — page size, tiling, bar styles, palette, timescale and the annotation layer all live there. See Output & templates.

⚠ Two honest limits in PDF output, stated here rather than discovered later:

1. Fonts are the standard set, not the template's. A template specifying a brand typeface plots in the standard face, and the what-you-see claim holds only as far as metrics happen to agree. This is the first thing to fix when a deliverable has to carry brand type.
2. Text is Latin-1 encoded. The common typographic characters map; anything outside that becomes a visible ? rather than silently vanishing, because a visible ? is a bug report and a missing glyph is not.

Schedule export#

A schedule now leaves as data as well as a picture, through File ▸ Export:

• CSV — the grid, flat, with a WBS code column carrying the hierarchy so the outline survives a format that has no notion of one.
• iCalendar — milestones and dated rows.

⚠ The calendar is a file, not a subscribable feed. It is written once and never updates itself, so a calendar built from it goes stale silently while continuing to look current. A feed is a URL the calendar re-fetches, and that needs a published-link surface which does not exist yet.

• .xlsx — the grid as a workbook, carrying the hierarchy as a real outline level rather than only a code column, under a frozen bold header.

⚠ The workbook carries no formulas, by decision. Durations, dates and rollups are computed by the scheduling engine from logic and calendars, and no spreadsheet expression reproduces them — a formula would recalculate into disagreeing with the schedule it came from. The numbers are exported as values, and they are the schedule's own.

The writer is hand-written — a store-only ZIP and the OPC parts — rather than a dependency, the same choice the PDF writer made.

Interchange with other scheduling tools is designed and not built:

Related#

• Output & templates — how a plot is laid out and styled.
• Views & filters — what a plot is a plot of.
• History and Comments — both travel in the file.