Customer context synthesis
Maintain durable customer facts without turning recollection into certainty. This method owns a current synthesis and an append-only source ledger for a named customer or account. Every substantive fact must trace to a stable source identifier and a host-accessible source or archive-pending pointer.
Resolve paths, source access, archival, and writes through `references/host-operations.md`. Do not assume a drive provider, mail system, repository, folder convention, or named user. If the host cannot authorize a write, return the proposed record changes and their evidence.
Modes
Infer the mode from the request. If a request combines modes, use `archive → capture → refresh → report → audit`.
`init`
Create the customer-context record, source ledger, and firsthand-notes record when the host has no established equivalent. Inventory supplied primary sources, assign source IDs, archive only authorized source material, and populate the first cited context record.
`capture`
Add supplied sources or explicitly supplied firsthand statements. Update the source ledger before changing the current synthesis. Preserve the user's wording in firsthand notes and keep it separate from interpretation.
`refresh`
Reconcile new material against the current context and source ledger. Add source IDs, mark conflicts without erasing history, and regenerate affected sections. Mark a source superseded only when a later source replaces it; ordinary disagreement does not invalidate either source.
`report`
Answer a customer question from the current context, citing source IDs and stating gaps or conflicts plainly. Do not mutate records unless the request also supplies new durable information.
`archive`
Save specifically authorized raw source material through the host archive operation. Reuse an existing source identity when present; do not create duplicates. A request to initialize, capture, refresh, or reconcile authorizes only the local context record unless it separately names archival.
`audit`
Validate the record, inspect source status and available host links, and report stale, uncited, disputed, or archive-pending items. Do not change substantive facts in audit mode.
Evidence rules
Assign source IDs monotonically as `SRC-001`, `SRC-002`, and so on; never reuse an ID. Classify source and claim evidence using the schema:
- direct customer evidence;
- attributed transcript;
- explicit firsthand statement;
- public source;
- derived analysis;
- inference; or
- unknown.
Treat customer-authored material and attributed transcripts as stronger evidence than a proposal or analysis that summarizes them. Treat machine transcripts as fallible; do not rely on one garbled phrase for names or exact numbers.
Firsthand capture
When a user explicitly asks to preserve firsthand information:
1. Identify the customer and exact factual statement. 2. Append a dated note with speaker, verbatim statement, context, and any interpretation on a separate line. 3. Redact credentials, payment data, health data, and unnecessary secrets; record that redaction occurred. 4. Archive a distinct raw snapshot only when that exact source is separately authorized. Otherwise keep the archive status pending. 5. Create exactly one source-ledger entry for every firsthand-note entry and link the current context fact to that source ID.
A firsthand assertion is evidence that the speaker said it, not independent proof that the customer confirmed it. Preserve conflicts until supported evidence resolves them.
Workflow
1. Resolve the customer
Use the host's canonical customer identity and context location. If two records could match, stop and ask which is canonical.
2. Read current state
Read the existing current context, source ledger, firsthand notes, and only the sources named by the user. Preserve unrelated user-authored changes.
3. Inventory sources
Prefer primary evidence: customer-authored material; attributed notes or transcripts; explicit firsthand statements; official pages; then analysis that cites its primary evidence. Identify a stable provider ID, revision, or content hash before adding a source. Reuse an existing source record when its stable identity already exists.
4. Reconcile before writing
For each fact, identify whether it is new, corroborating, contradictory, or a correction. Do not select a winner silently when evidence conflicts.
5. Update the source ledger first
Append a complete source record using `references/artifact-schema.md`. Include what it supports and its reliability limits. Mark old records rather than deleting them.
6. Update the current context
Maintain concise sections for technology, organization, processes, stakeholders and goals, and open questions or conflicts. Put one factual proposition per row with evidence labels and source IDs.
7. Archive and link
Archive missing raw sources only with separate authorization. If archival fails or is not authorized, retain an archive-pending status and do not claim the record is fully synchronized.
8. Validate and report
Validate the schema, resolve every error, explain warnings, and report customer, mode, changed source IDs, record locations, archive status, conflicts, and proposed handoffs.
Ownership boundaries
This method owns customer facts and provenance. It does not change relationship stages, task records, reusable quote evidence, raw meeting archives, or outgoing messages. Propose the relevant host-owned workflow when source material creates one of those needs.