Corporate documents

Meeting minutes have a part that is text —what was discussed, why something was decided— and a part that is data: who attended, which actions were left open, by when and by whom. In practice both parts end up in the same text document, and the data is recovered later by reading: someone goes through the quarter's minutes to find out which actions are still open, or copies the status of twenty reports into a spreadsheet.

The problem is not the text format but that the data is not marked as such. STXT solves exactly that: data are nodes with a name and a value, text goes in literal blocks, and the document still reads top to bottom as it always did.

Meeting minutes

The minutes of a weekly meeting, as the person taking them would write them:

Minutes (com.acme.corp.minutes):
	Title: Weekly sync — Platform
	Date: 2026-01-09
	Duration minutes: 45
	Attendees:
		Attendee: Joan Costa
		Attendee: Mery Adams
		Attendee: Keyla Brown

	Notes >>
		The quarter's roadmap is on track, but the team's capacity for February is
		still open. The main risk is still the external provider dependency in
		module X: response times vary too much from day to day.

		Agreed to move the deployment window from Friday to Monday, to have full
		support the following day. The cost of option B will be reviewed before
		deciding on the cache.

	Decisions:
		Decision: Move the deployment window to Monday
			Id: DEC-0142
			Decision status: Approved
			Owner: Platform Team
			Rationale >>
				Reduces operational risk: Tuesday support is full, Saturday support
				is not.
		Decision: Freeze non-critical changes in module X
			Id: DEC-0143
			Decision status: Proposed
			Owner: Reliability

	Actions:
		Action: Prepare the quarter's capacity proposal
			Id: ACT-0991
			Owner: Mery Adams
			Due: 2026-01-16
			Action status: Open
		Action: Estimate the cost of option B
			Id: ACT-0992
			Owner: Joan Costa
			Due: 2026-01-14
			Action status: In Progress

It reads like minutes. And at the same time, for a program, it is a tree in which every action has an owner, a date and a status.

What is data and what is text

That is the only modelling decision to make, and the criterion is practical: data is what someone will search, filter or count; text is everything else.

• Attendees, decisions and actions are data: they are listed, cross-referenced with other minutes, they fall due. They go in inline nodes, one per element.
• The summary of the discussion and the rationale of each decision are text: they are read, not processed. They go in >> blocks, where paragraphs are written without any restriction.
• The title of each decision and each action is the value of the node itself (Decision: Move the deployment…), and its attributes are children. That way the list reads at a glance.

If later something that is text today needs processing —the risks mentioned in the notes, for instance—, it is moved to a node of its own. The document does not change format; it gains a node.

The template

A template fixes what every set of minutes must have and what is optional, and narrows the statuses:

Template (@stxt.template): com.acme.corp.minutes
	Description >>
		Minutes: Meeting minutes
		Decisions: Decisions taken or proposed in the meeting
		Actions: Agreed actions, with owner and due date
	Structure >>
		Minutes:
			Title: (1)
			Date: (1) DATE
			Duration minutes: (?) NATURAL
			Attendees: (1)
				Attendee: (+)
			Notes: (?) TEXT
			Decisions: (?)
				Decision: (*)
					Id: (1)
					Decision status: (1) ENUM [Proposed, Approved, Rejected]
					Owner: (?)
					Rationale: (?) TEXT
			Actions: (?)
				Action: (*)
					Id: (1) @Id
					Owner: (?) @Owner
					Due: (?) DATE
					Action status: (1) ENUM [Open, In Progress, Done, Blocked]

What it guarantees, minutes after minutes:

• Every set of minutes has a title, a date and at least one attendee; without that it does not validate.
• A decision is in one of three statuses, and an action in one of four. A status written any other way (Approved., open) is an error, not a variant.
• Dates are dates: 2026-01-32 does not pass.
• A node that is not in the template —Atendees with a single t, a Priority someone added on their own— is rejected. That is the closed content model: the template is the complete list of what may appear.
• Id and Owner are declared once and reused with @Id and @Owner: within a namespace, a node name identifies a single node. By the same rule, the status of a decision and that of an action are different nodes —Decision status and Action status—: their value lists differ, and one name cannot have two definitions.

The template is stored in the .stxt/ directory of the repository where the minutes live, and from then on the editor and the command line apply it with no configuration (Working environment).

A status report

The same approach serves any periodic document. A weekly status report:

Status Report (com.acme.corp.status):
	Project: Customer portal
	Owner: Platform Docs
	Period:
		From: 2026-01-05
		To: 2026-01-09
	Status: Green

	Summary >>
		Steady progress on the base documentation. Work remains on the command
		line tools and the use cases; none of it blocks the February delivery.

	Progress:
		Item: Introduction page
			Item status: Done
		Item: Tutorial
			Item status: Done
		Item: Command line reference
			Item status: In Progress

	Risks:
		Risk: Missing migration examples from other formats
			Id: RSK-020
			Level: Medium
			Mitigation >>
				Prepare two migration examples before the end of the quarter.

Template (@stxt.template): com.acme.corp.status
	Description >>
		Status Report: Periodic status report of a project
	Structure >>
		Status Report:
			Project: (1)
			Owner: (1)
			Period: (1)
				From: (1) DATE
				To: (1) DATE
			Status: (1) ENUM [Green, Amber, Red]
			Summary: (1) TEXT
			Progress: (?)
				Item: (*)
					Item status: (1) ENUM [Done, In Progress, Blocked]
			Risks: (?)
				Risk: (*)
					Id: (1)
					Level: (1) ENUM [Low, Medium, High]
					Mitigation: (?) TEXT

The Status traffic light is an ENUM, not an adjective in the summary. With twenty reports in a directory, a ten-line script answers how many projects are red and what their high risks are, without anyone having read them one by one.

In the workflow

The documents live in a repository, like code:

• Writing: any text editor. With the VS Code extension, the template provides completion of names and statuses, and marks errors while typing.
• Review: a change is a diff of specific lines —an action going from Open to Done, a new decision—, not a binary file that has to be opened to see what changed.
• Continuous integration: stxt validate --recursive minutes/ rejects incomplete minutes or an invalid status before they reach the repository (The command line).
• Exploitation: the canonical tree (stxt describe, or the library of each language) feeds whatever is needed: the list of open actions per person, a weekly summary by email, a dashboard with every project's traffic light.

None of this forces a change in how people write: minutes without a template are a valid STXT document, and validation is added when the team decides what it wants to guarantee.

Limits

STXT structures the document; it provides no approval workflow, access control or notifications. Those come from the repository and the tools around it. Nor does it validate rules between fields —that an action in Done status has no future date, for instance—: that logic belongs to the application that exploits the data, not to the template.

The neighbouring genres follow the same approach: RFCs and technical proposals for documents with a life cycle, and contracts where the data lives inside normative text. The language behind the examples is covered, rule by rule, in the tutorial.