Observed pattern
A manual progress-report review reveals common information structures and review needs. It does not establish Jaywalker’s exact workflow.
September 3, 2026 · Product discovery workshop
OpenLine ×
Jaywalker Lodge
A working conversation about keeping the right people informed—without creating another clinical record.
Facilitated by Standard Bureau · Exploratory, not an approved product plan
Why this conversation matters
The referral relationship is one continuous experience.
The work crosses teams and systems, but the referring partner experiences every gap as the same question: “What happens next?”
- 01AvailabilityIs this the right place, right now?
- 02IntroductionCan I make a warm, trusted handoff?
- 03AdmissionsWhat is needed, and where does it stand?
- 04Treatment visibilityWhat can I responsibly know?
- 05AftercareHow do we support continuity?
Source basis: OpenLine product model; workshop framing to validate with Jaywalker
Source discipline
We have three kinds of evidence—and they should not blur.
Repository fact
OpenLine already models parties, category-scoped releases, append-only consent history, referral stages, and server-side feed enforcement.
Discovery assumption
Any Jaywalker workflow, Kipu field, mapping, cadence, or automation remains unvalidated until the responsible team confirms it.
Repository facts: PRODUCT.md and KIPU.md · Manual review described only in generalized, de-identified form
Proposed product boundary
OpenLine should coordinate trust without becoming the chart.
Kipu
Clinical system of record
Census, episodes, documentation, care data, and center-specific forms remain where clinical work happens.
minimum necessaryreviewedrelease-governed
OpenLine
Controlled collaboration layer
Referral status, approved updates, permissions, messages, and a durable record of what was shared with whom.
The value is not “more data.” It is reliable coordination with a clear sharing boundary.
Repository hypothesis: Kipu remains system of record; integration is planned and not validated with Jaywalker
Core-user map
Five operating roles shape the experience.
The client controls disclosure. These five roles make the day-to-day workflow succeed—or quietly route around it.
OpenLinecontrolled collaboration
Professional referents
Admissions & financial coordination
Clinical liaisons
Referral, alumni & outcomes
Tenant admins & integration owners
Working role map synthesized from PRODUCT.md and the discovery brief
Core user 01
Professional referents need continuity they can trust.
- Who they are
- Interventionists, therapists, consultants, and case managers who place or support a person entering care.
- What they do today
- Coordinate the introduction, support family members, and chase status through calls, texts, or email.
- What they want
- A dependable view of referral status, approved progress, transition planning, and a private line to the team.
- What they carry
- Trust with the family, uncertain timing, incomplete permission, and concern that visibility could disappear after placement.
Workshop prompt: What information earns trust—and what would feel like overreach?
Role supported by PRODUCT.md; current Jaywalker workflow is a discovery question
Core user 02
Admissions needs one clean handoff, not another inbox.
- Who they are
- Admissions and coordination staff who qualify the referral, gather intake information, and move it toward a decision.
- What they do today
- Resolve missing details, insurance information, availability, fit, and acceptance across people and systems.
- What they want
- A complete referral packet, a visible status, clear ownership, and less re-keying when the person is accepted.
- What they carry
- Sensitive intake data, time pressure, duplicate work, ambiguous responsibility, and the risk of exposing financial information too broadly.
Workshop prompt: Which status changes can be automatic, and which require a human message?
Referral stages and intake boundary: PRODUCT.md · Financial workflow remains unvalidated
Core user 03
Clinical liaisons need safe reuse, not duplicate documentation.
- Who they are
- Clinicians, case managers, or treatment-team liaisons responsible for approved external communication.
- What they do today
- Interpret progress, decide what can be shared, answer questions, and preserve clinical context.
- What they want
- A fast review-and-share step, visible audience scope, and confidence that the release controls the final view.
- What they carry
- Clinical workload, contextual nuance, permission changes, stale data, and the harm of an automated update arriving without review.
Workshop prompt: What is the smallest review action that still feels clinically responsible?
Composer preview and staff-authored updates are repository roadmap items, not production capabilities
Core user 04
Relationship teams need a durable thread beyond discharge.
- Who they are
- Referral-relations, alumni, and outcomes staff who maintain professional trust and support continuity.
- What they do today
- Coordinate follow-up, maintain relationships, and piece together what can appropriately be communicated.
- What they want
- Clear handoffs, approved report history, follow-up ownership, and visibility into whether the relationship is still active.
- What they carry
- Post-discharge ambiguity, changing consent, unclear ownership, and pressure to show value without turning care into a metric.
Workshop prompt: When should OpenLine’s responsibility end—and when should it evolve?
Discharge and alumni behavior is a roadmap area in PRODUCT.md
Core user 05
Administrators need proof the boundary holds.
- Who they are
- Center administrators, security owners, and integration operators accountable for configuration and access.
- What they do today
- Provision users, manage vendor access, investigate exceptions, and reconcile systems when data drifts.
- What they want
- Tenant isolation, auditable changes, scoped credentials, health visibility, and a safe path to revoke access.
- What they carry
- Vendor risk, cross-tenant exposure, credential handling, incomplete logs, and a sync that fails open or silently ages.
Workshop prompt: What evidence would make a pilot safe enough to begin?
Security posture is a product principle; compliance and production readiness are not claimed
Affected stakeholders
Clients set the sharing boundary; families live with its consequences.
Person of concern
Control should be legible.
They may become a direct user for release signing, revocation, and visibility into what has been shared. The repository supports this distinction, but self-service is still on the roadmap.
Family members
Access should be intentionally smaller.
They are modeled as parties with their own release—not as automatic recipients. Their needs may include logistics and family work without receiving restricted clinical context.
One person can share different categories with different people—and change that decision later.
Source: PRODUCT.md roles, default-category distinction, and append-only release history
End-to-end journey
Every handoff creates a moment of uncertainty.
- Bed & fitAvailability changes quickly.Who confirms?
- Warm introductionContext changes hands.What is necessary?
- Referral reviewDetails arrive unevenly.What is missing?
- AcceptanceSystems and owners change.Who takes over?
- AdmissionPermission becomes active.Who can see what?
- Treatment updatesProgress needs interpretation.Who reviews?
- TransitionPlans remain provisional.Who coordinates?
- Follow-upConsent and ownership evolve.When does access end?
Journey synthesizes repository lifecycle and discovery hypotheses; sequence to validate with Jaywalker
Exploratory concept 01 · Synthetic demo data
A summary could answer “Where are we, and what can I know?”
One glance joins program stage, review status, sharing scope, and the next coordination steps.
Synthetic, exploratory concept · Not brand-approved, production-ready, or a validated Kipu view
Exploratory concept 02 · Synthetic demo data
The journey view could separate client and family engagement.
Program movement, structured activity, and family participation can be legible without turning the page into a photo stream.
Synthetic, exploratory concept · Program mapping and data availability are unvalidated
Exploratory concepts 03–05 · Synthetic demo data
Reviewed progress should preserve context, state, and limits.
All interfaces are synthetic and exploratory · No capability, compliance, or outcome claim
Generalized manual report review
A progress report is a governed narrative—not a data dump.
Orient. Program journey and reporting period establish where the person is.
Show provenance. Cadence, source, and human review should stay visible.
Separate participation. Client engagement and family engagement are related, not interchangeable.
Structure the story. Progress themes and activities communicate more safely than a photo stream.
Preserve limits. Clinical context, authorization, missing states, and instrument-specific scales cannot be flattened.
Carry continuity. Transition planning, approved history, and follow-up ownership matter after the report is read.
Derived from a de-identified manual progress-report review; no source wording or identity reproduced
Data and integration
Start with census and status; earn every additional field.
Repository-documented plan
- Kipu remains the system of record.
- A planned poll maps census and lifecycle changes into OpenLine.
- Accepted referrals may push a narrow pre-admission record.
- Raw EMR notes should never auto-publish to parties.
Questions for Jaywalker + Kipu
- Which instance, programs, locations, and episodes are in scope?
- Which statuses and levels of care are reliable enough to map?
- Where do referral contacts, consents, and external IDs live today?
- Which fields require center-specific forms or clinical interpretation?
- How should latency, outages, duplicates, and readmissions appear?
Source: docs/KIPU.md, which itself requires verification against current docs and Jaywalker’s instance
Product principles
The boundary must be understandable before it is powerful.
- 01Minimum necessary by designShare categories, not indiscriminate records.
- 02Explicit scope and lifecyclePurpose, expiry, supersession, and revocation stay visible.
- 03Tenant isolationRelationships define access; identity alone never does.
- 04AuditabilityChanges to visibility and first views leave a durable trail.
- 05Human review at the edgeNo duplicate clinician note—and no blind auto-publish.
- 06Fail closedStale or unavailable integration data is labeled and withheld when necessary.
Grounded in repository access rules and requested pilot safeguards; not a compliance determination
Pilot boundaries
A safe pilot should prove coordination before it expands content.
Use synthetic or approved test datauntil safeguards, contracts, credentials, and workflows are verified.
Choose one program and one referral cohortwith a named operational owner and escalation path.
Begin with status and reviewed updatesbefore clinical detail, assessment data, or automation.
Measure workload and trustwithout promising utilization, referral, or treatment outcomes.
Stop safelywith revocation, audit export, stale-data behavior, and a clear end date.
Proposed discussion boundary · Not approval for production data or production deployment
Brainstorming · Users + workflow
Where does trust break today?
UsersWho owns the referent relationship before admission, during treatment, and after discharge?
UsersWhat does each role need to know—and what should remain deliberately unavailable?
WorkflowWhich handoff causes the most repeated outreach or uncertainty?
WorkflowWhat update already exists and could be safely reused after a short human review?
WorkflowWhat event needs a personal conversation rather than a portal notification?
Facilitated prompts for Jaywalker and Standard Bureau
Brainstorming · Data + privacy
What must be true before anything crosses the boundary?
IntegrationWhich Kipu status is authoritative, and how fresh must it be to display?
IntegrationHow should we reconcile duplicate people, readmissions, or program transfers?
SharingWho proposes, signs, expires, and revokes each release?
PrivacyWhat should the recipient see when access is missing, changed, or revoked?
Pilot successWhat evidence would demonstrate value without implying a clinical outcome?
Facilitated prompts; legal and compliance conclusions require qualified review
The decision to leave with
What is the smallest first pilot that is unmistakably useful—and adds no clinician workload?
One cohort. One relationship owner. One reliable status source. One reviewed update pattern. One clear stop condition.
If we can name that pilot together, the next step is a workflow and data-validation session—not a production launch.
OpenLine × Jaywalker Lodge · Standard Bureau · September 3, 2026