Shared workA system walkthrough · October 17, 2026
A practical look at what I already had, what a peer conversation helped sharpen, and the upgrades now in the system.
An October 15 conversation helped me make the exchange visible: what someone offers or needs, the project it belongs to, and what we can responsibly share. I used that lens to improve a working contact and weekly email setup.
Walk through the changes
Keep the context.
The system is called Contacts & Collaboration.
Its main entry point is the $contacts skill.
Established weekly workflow
reviewed exchange records
explicit sharing scope
The starting point
The upgrade builds on contact profiles and a weekly relationship workflow.
Before this change, the setup held individual contact context and preferences and produced recipient-specific HTML and plain-text email, with filtered companion material and feedback links. The recurring schedule was Thursday at 8 a.m. Phoenix time. A separate digest supported my own review.
That gave the system a useful delivery path. The next question was how to keep a person, their participation in a program, and a particular exchange from becoming one tangled record.
October 8: three separate recipient sends.
October 15: five separate recipient sends, plus my separate digest. Fresh provider readback confirms all six in Sent.
The October 8 count is recorded in the existing history. The October 15 count also has fresh provider Sent metadata. Neither tells us whether a recipient received or read a message, found it useful, or took action.
The approved email design, artwork, sender, weekly schedule and delivery history remain in place. This change improves the records and checks underneath that workflow. Rich automatic interaction history was not part of the prior system.
One correction from the earlier email work: the original packaging was oversized, and the asset contract was later compacted. Package size is something I can inspect. Inbox placement and recipient headers need their own evidence.
An October 15 peer exchange
A collaborator described a broader system they are still testing and packaging. I borrowed a bounded part of it.
The AI-generated notes from the 52-minute conversation describe connection and interaction capture; a landing-zone inbox; wants, needs, offers and requests; shareable manifests with explicit visibility; project indexing; impact reporting; offline ZIM exchange; and flexible publishing.
From the described approach
Give an interaction enough context to be useful later.
Adapted here
Keep a captured item distinct from a reviewed record.
Adapted here
Make the person, project and intended audience explicit.
The parts I adopted are reviewed exchange records, explicit sharing scope, person and project context, and links from a contribution to an outcome. Those ideas informed this upgrade; the broader approach remains the collaborator’s work.
Broad inbox scans, automatic matchmaking or introductions, and whole-vault offline export are deferred. A landing zone can be useful, but collecting more material also creates a review and maintenance job. For now, I want each captured exchange to earn its place.
ZIM exchange and flexible publishing remain ideas from the described approach. This upgrade does not implement them.
Implemented in this upgrade
The records now give identity, participation, exchanges and sharing different jobs.
| Part of the system | Before this upgrade | Now implemented |
|---|---|---|
| Person | Individual profiles supported the existing workflow. | Five existing profiles are normalized into one canonical contact set, each with a stable identifier. |
| Program participation | The prior structure served the recurring contact program. | Membership is separate from identity. A person and their participation can be maintained independently. |
| An exchange | There was no automated rich interaction history. | A dedicated exchange history distinguishes captured material from reviewed records and can retain person and project context. |
| Sharing | The delivery workflow had its own recipient context. | A separate share history makes the sharing scope and the reviewed handoff explicit. |
| A contribution’s result | Send history showed recorded delivery activity. | Exchange records can link a contribution to an outcome. A link still needs evidence of what actually happened. |
A compatibility projection keeps the existing contact-file contract available to the email workflow. The email builder also checks the data before building: if the required contact data fails validation, the build stops.
Per-person context is constrained to what is safe and relevant for that person. Private health or accessibility details and other people’s context are excluded from that output. A current display-name correction keeps older identifiers only where historical matching or existing provider and feedback links need them.
The skill’s entry point is $contacts, under Contacts & Collaboration. Historical internal names are retained where compatibility needs them; they do not define the current system’s name.
The installed skill is enabled. Existing profiles have migration-context records, and a feedback example from an AI meeting summary is explicitly marked as transcript-unverified. Historical share pointers reference existing history. These initial records make the model inspectable; they are not evidence of new collaborative outcomes.
Local behavioral checks pass. Preview replays of archived weekly editions preserve the HTML and previews, with equivalent complete plain-text and MIME payloads. The protected delivery ledger, template and assets remain unchanged. These checks used archived inputs in preview mode; no new message was sent by the replay.
How it works now
The review boundary matters more than how much the system can collect.
Use the canonical contact and the relevant project or program context. Keep an address or an old filename from becoming the person’s identity.
Record what was offered, needed or requested, with enough source context to review it. Captured material stays distinct from a reviewed item.
Check the person, project, meaning and sharing scope. Use the safe context for that person. A useful private note is not automatically shareable.
Keep the share or delivery event separate from the prepared content. Add an outcome only when there is evidence to support it.
Synthetic example · no real contact data
“I can review a one-page workshop outline this month.”
The offer is recorded with its context. It still needs review before reuse or sharing.
The intended people, meaning and scope have been checked. Sharing is a separate action, with its own record.
This illustrates the model. Opening this example does not create a record, contact anyone, or send a message.
The weekly email routine continues on its existing schedule. These upgrades give it cleaner contact data and a more explicit context boundary. The new exchange model also supports collaboration outside that recurring program.
Constructive feedback for continued testing
The most promising idea for me is a small, reviewable exchange that can carry its context into the next piece of work.
An inbox is useful if people can tell what is raw capture, what has been checked and what has become durable context. A single recent interaction is a good test: can a person recover the source and correct its meaning without searching the whole system?
A manifest should answer “Who can see this, and which part?” in ordinary language. Test the explanation with a collaborator before the handoff, then compare the explanation with the material that actually travels. A technical visibility flag alone is easy to misread.
Wants, needs, offers and requests are useful prompts. They still need context: timing, intended people and what the person meant. An offer is a starting point for a conversation. It is not permission for an automatic introduction or a new commitment.
Link a concrete contribution to an observable result, and keep who reported it visible. “An outline was reviewed” and “the workshop improved” need different evidence. A connection in the record helps us investigate the relationship; it does not establish causation.
For offline exchange, I would start with a curated, explicitly scoped package and synthetic material. Check its contents from the recipient’s view and confirm the intended boundary. That would help test the exchange contract while the broader system continues to take shape.
If the real job is a good weekly email, a lighter contact setup may be enough. The extra exchange and share records earn their place when they help us recover context or avoid a sharing mistake without adding a second administrative job.
For continued testing and packaging, I would compare one small exchange from capture through handoff: could each person explain what was recorded, what could be shared, and what happened next? That is a useful next experiment, rather than a result we can claim already.
Sources and limits
All examples on this page are synthetic. No contact addresses, individual preferences, private records or private source downloads are included. This is a description of Kyle’s setup and a bounded response to ideas shared in that peer exchange.
A useful exchange can stay small.
A useful peer exchange gave me a concrete way to improve the system I already use. The next evidence has to come from using it.
Back to the beginning