# Memory: what carries forward

> Carry forward what your team has chosen to keep: reviewed decisions, current facts and working records that give the next session a place to begin.

<a id="firm-decisions-what"></a>

## Firm decisions — What they are

Operating decisions your firm has agreed, with their rationale and scope, kept distinct from the reusable standard they may eventually update.



<a id="firm-decisions-use"></a>

## Firm decisions — Record one

“We decided” writes a decision with rationale, status and date. Decisions are never edited in place; a change supersedes the earlier one and keeps the history, so a proposal is never mistaken for an approval.

Ask Norma: Norma, record this decision: [what was decided, by whom, and why]. Write it with its rationale, status and date, and tell me which earlier decision it supersedes, if any.



<a id="firm-decisions-extend"></a>

## Firm decisions — Keep it current

Supersede rather than delete. A reversed decision stays legible as history, which is what the next reviewer needs.



<a id="project-context-what"></a>

## Project context — What it is

A project is a folder your firm owns. PROJECT.md holds the sourced current facts; decisions holds the durable reasoning; tasks, meetings and site reports each keep their own typed record. There is no shared project database behind Arch Studio and no synchronization between Claude and ChatGPT; both read the same files.

The top of a real project file · skills/project/templates/PROJECT.md:

# Project — {{PROJECT_NAME}}

> Every fact carries a source and date. Decision rationale lives only in `decisions/`.

## Identity

| Field | Value | Source | Date |
|---|---|---|---|
| Project ID | {{PROJECT_ID}} | project setup | {{CREATED_DATE}} |
| Type | {{PROJECT_TYPE}} | project setup | {{CREATED_DATE}} |
| Status | {{PROJECT_STATUS}} | project setup | {{CREATED_DATE}} |

## Project records

- Decision records: [decisions/](decisions/)
- Meeting minutes: [meetings/](meetings/)



<a id="project-context-use"></a>

## Project context — Set one up

Ask Project records to initialize a project: display name, internal or client, status and a code convention. The preview writes nothing; apply creates the folder, the project file and the registers, then reads them back. Facts carry a source and a date so the next person can judge whether they are still current.

Ask Norma: Norma, set up a project record for [project name]: [internal or client], status [status], client [client]. Preview the files first, then create them after I confirm.

- [Project records](https://architecturestudio.ai/capabilities/skill-project)

<a id="project-context-extend"></a>

## Project context — Change or remove

Update a fact with its new source and date, or ask the assistant to and read the diff before it writes. Remove a project by deleting the folder; nothing about it remains in the service, because nothing about it was ever sent there.

Ask Norma: Norma, update this project fact: [fact], source [source], date [date]. Show me the diff before you write it.



<a id="working-records-what"></a>

## Working records — What they are

Tasks, meeting records, selections, decisions and issued deliverables, each in its own record with an owner and a status. A conversation is not a record; something is kept when it is deliberately recorded and reviewed.

How the assistant is told to treat the records · skills/project/templates/AGENTS.md:

# {{PROJECT_NAME}} — Project Instructions

- Read `PROJECT.md` before project work.
- Treat `decisions/*.md` as the sole decision source of truth.
- Before making scope commitments, read `agreement/AGREEMENT.md` when it exists.
- Preserve typed ownership for meetings, site reports, tasks, plans, and time.
- Use project-relative links and never persist machine-specific absolute paths.



<a id="working-records-use"></a>

## Working records — Use them

A session starts from the records, not from a summary. Minutes carry decisions and actions; the task register carries owners and dates; the assistant reads them before project work because the project instructions say so.

Ask Norma: Norma, turn these meeting notes into minutes with decisions and action candidates: [paste notes]. Save them to this project’s meetings folder and tell me which actions you propose adding to the task register.



<a id="working-records-extend"></a>

## Working records — Add a record type

A new register needs an owner skill, a file location and a status vocabulary. Keep typed ownership: the skill that writes a record type is the only one that changes it.



<a id="continuity-what"></a>

## Continuity — What it is

A handoff with next actions, unresolved questions and links to the work. The next person, or the next session, resumes from those files and verifies what has changed.



<a id="continuity-use"></a>

## Continuity — Hand off

Ask for a handoff at the end of a session. It names the records to open, the decisions in force, the open questions and the next review action.

Ask Norma: Norma, prepare a handoff for this project: what was done this session, which records changed, what remains open and what the next person should do first.



<a id="continuity-extend"></a>

## Continuity — Where it ends

Usage records in the hosted service are separate from your project files: bounded events about the connection, never prompts, outputs or files, removed on account deletion or on request.

- [Privacy and data handling](https://architecturestudio.ai/privacy)

<a id="get-started"></a>

## Get started.

Connect Arch Studio to the Claude or ChatGPT account your firm already uses, then paste this into a new chat.

Norma, set up a project record for [project name], record one decision we made this week with its rationale, and prepare a handoff so the next person can pick it up from the files.

- [Connect Arch Studio](https://architecturestudio.ai/docs/install)
- [All four pillars](https://architecturestudio.ai/#framework)