MiddleGroundGive fields a shared meaning.
A field can be text, a number, a boolean or a set of named values. For example, agree that a work estimate is a number and explain what it measures. Adding a definition does not rewrite existing values.
Working together
Pick up the work.
Keep the understanding.
Different people, different conversations, one shared source. Keep the purpose, actions and information with the work so the next person or assistant has somewhere to begin.
From discussion to action
The next steps belong
with the project.
A tasklist artifact turns a Markdown checklist into an interactive task view. Headings group the work, indentation keeps subtasks together and checkboxes hold the completion state.
One list, two ways to work.
Check off a task in the task view, or ask your assistant to update the same document. The Markdown remains the source, readable outside MiddleGround too.
“Turn our agreed next steps into a tasklist on this project. Keep preparation and site work separate.”
Tasks, Visual and Source offer different ways to view or edit the document. This is a project checklist; it does not imply automatic reminders or a scheduling engine.
Example · the underlying Markdown
# Site visit
- [x] Confirm the appointment
- [ ] Prepare the visit
- [ ] Gather the existing drawings
- [ ] List the open questions
- [ ] Record the decisions afterwardsMarking a task complete changes its checkbox in this same document. Tasklist profile metadata identifies its task view.
A shared starting point
Keep the purpose.
Carry the agreements forward.
Record what your Environment is for and how you work. Another connected conversation can read that context before adding its contribution.
Describe the work.
Tell the assistant what you want to organize. It can inspect the Environments you have authorized and help choose one, or create one when you have granted that capability.
Keep useful agreements.
Save the purpose and working agreements with the Environment: how to distinguish decisions from suggestions, which sources matter, or what should be reviewed.
Continue in context.
In a later conversation, select the intended Environment and ask the assistant to read its purpose and agreements. The information is available across conversations; the assistant still needs to consult it.
Illustrative working agreement
“This Environment holds our renovation project. Keep confirmed decisions separate from ideas. Record the source of a cost estimate and ask when information is missing.”
Working agreements provide context. They do not grant permissions or guarantee an assistant will follow every recommendation.
Agree on what information means
Room for flexible work.
Structure where it helps.
Define the meaning and type of shared fields, then describe which information is useful for a kind of Thing. People and assistants can work with the same definitions.
Recommend or require.
Start with advisory checks that show missing or invalid information. Where supported, required rules reject semantic writes that do not meet the agreed fields and values. Extra fields can still be allowed.
Review before changing rules.
An assistant can preview the effect of a proposed data description and assess existing information. Older records remain readable even when a new rule makes them incomplete.
Build on information you have.
Use definitions to help construct filtered overviews and guide assistant updates. Validation checks structure and values; it does not establish that a fact is true or invent missing information.
Stay with the work
See what changes.
Choose who participates.
A recent activity centre.
The web app’s notification bell brings recent changes together. Relevant notifications can take you to the affected Thing, artifact or Context; Whiteboard activity is included.
Access stays explicit.
Environment and Thing permissions determine what each person can read or change. Connected assistants also need the appropriate access grant. A View, Report or Whiteboard does not bypass that access.