
Orchard House · DL-1042 · Origination
I’ll check with the reviewer.
Case study
This collection is private for now. Enter the password to view.
← Return to mikebatts.net
Ray by Daylight
Daylight’s AI concierge for origination.
Origination
142 Orchard Lane · DL-1042
What’s holding this project up?
Alex Morgan · Just now
Orchard House · DL-1042 · Origination
Ray can make mistakes. Check important info.
I conceived, designed and engineered Ray.
Then shipped it, and kept making it better.
A solar project has a lot
of moving parts.
Documents, requirements and questions are spread across the project. I built Ray to make that information easier to use.
01What we learned from Notes
Ray started with a review of more than 3,000 portal notes. We wanted to understand what partners were asking and where they got stuck.
of notes tagging someone
received no reply.
asked something Ray could answer
from information we already had.
Notes gave us the research: attachments, mentions and notifications made it possible to see what partners were asking and where replies were missing. The 90% finding describes questions answerable from existing information, not a measured accuracy rate for Ray.
I built Ray around those questions. The goal was to make project data and guidance easier to get, without needing someone else to look it up.
02Documents
Ray finds project documents and helps place new files. You review the destination before anything is filed.
Orchard House · DL-1042 · Origination
Ray can make mistakes. Check important info.
Orchard House · DL-1042 · Origination
Ray can make mistakes. Check important info.
Review the project and document type.
Ray retrieves project documents through authenticated links. For a new file, I designed a concierge that proposes where it belongs. The person checks the project and category, then confirms.
Make the destination visible before anything changes.
03Sheets and artifacts
Users can ask for the project data they need and get a sheet built around that request. This became the starting point for Ray’s artifacts.
Created in the conversation
Show installation reviews with their status and feedback.
I created a sheet for those reviews.
Installation reviewsOpen sheetSaved outside the chat.
Reopen it. Share it. Download it.
Saved Sep 2, 9:40 AM
| Project | Review | Feedback |
|---|---|---|
| Orchard House | Rejected | Photo is missing |
| Juniper House | Rejected | Document needs review |
Frozen when saved.
Reopened Sep 5, 4:12 PM
| Project | Review | Feedback |
|---|---|---|
| Orchard House | Rejected | Photo is missing |
| Juniper House | Approved | Reviewed Sep 4Changed on reopen |
| Cedar House | Rejected | Roof measurement is unclearAdded on reopen |
1 record changed, 1 added since the file was saved.
A beta request for review data first led to CSV exports. I then built live sheets: choose the fields and filters in chat, and keep the result as a saved artifact. A sheet stores the query, not frozen rows.
Artifacts give the output its own place outside the conversation. Sheets were the first type. Each saved sheet has a link, reruns against current data and respects the viewer’s access. CSV download is still available.
04Across the portal
Use Ray beside a project, across the page or in a separate window. The conversation and draft stay with you.
Project
Title verification Needs review
The portal changes.
The conversation stays.

Orchard House · DL-1042 · Origination
I’ll check with the reviewer.
I gave Ray a drawer, full page and separate window inside our existing HTMX and Stimulus portal. Turns run on the server, so a new page can reconnect to an answer already in progress.
Eligible users reach Ray from a desktop floating launcher. On phones, a top-bar entry keeps project actions clear.
Fit the assistant to the workflow, not the other way around.
A separate window takes over the conversation and minimizes the drawer. Buffered server turns separate the work from the page displaying it. Links wait for HTMX-loaded project cards before focusing them. Stale runs expose recovery instead of an endless spinner; navigation resilience is not a guarantee across a server restart.
05Search and retrieval
Ray searches project records, notes and Daylight guidance. Sources are attached so users can check the answer.

Ray can only see projects visible to you.
Ray can make mistakes. Check important info.
Two kinds of context.
One useful answer.
Knowledge baseHow Daylight works
Project notesWhat happened here
Ray began with keyword search and citations. I added semantic retrieval alongside it, combining both rankings across the relevant knowledge base and accessible notes. Saved and edited notes are indexed in the background.
Expand how Ray finds information without losing its source or access boundaries.
Reciprocal rank fusion combines keyword and vector results. Scope is applied before ranking. Portal and customer knowledge remain separate; keyword search remains the fallback. This is retrieval over indexed content, not a model learning permanent memories or a claim that every answer is correct.
06Support
Ray prepares a support request with the conversation and project attached. You review it before sending.
Orchard House · DL-1042 · Origination
Ray can make mistakes. Check important info.
Document review
Intercom · OpenConversation and current page
Available to the support teamReview what goes to support.
I made Ray a first stop in Daylight’s support stack. A reviewed request reaches Intercom with the project and conversation. The next iteration added a staff-only Activity Log for inquiries, support cases and refreshed ticket status.
Connect AI assistance and human support as one experience.
07Homeowners
Homeowners can find their documents, ask about their system and contact Daylight support.
Where’s my signed agreement?
Here’s the signed agreement for your home.
Ray can make mistakes. Check important info.
I built the shared backend for customer guidance, personal documents and support requests. Our iOS engineer implemented the native conversation and cards. Homeowner access stays separate from the partner portal.
The homeowner Ray foundation predates the portal beta. I owned Ray end to end, including its product direction and backend; our iOS engineer implemented the native conversation and document/support cards. Their merged implementation and my backend changes establish the collaboration, not the rollout status of every app feature.
Engineering
Ray runs inside Daylight’s existing stack. I built the shared service, portal interface, retrieval and tool workflows.
Ray serviceThe model and tool loop sit behind both experiences. The portal uses server-rendered views with small JavaScript controllers.
Python · Django · Jinja
HTMX · Stimulus · Tailwind
Turns run on the server. Buffered events reconnect when the view changes, and completed messages are saved.
Responses API · SSE
Redis · PostgreSQL
Search is scoped before results reach the model. Actions require confirmation and a fresh access check on the server.
pgvector · BM25
Scoped queries · Confirmed actions
Shaped by the work
I designed and engineered Ray, then kept iterating with partners during the beta.
The questions partners were asking informed the portal concierge.
Implementation record · Backend PR 1562Requests for review data led from CSV exports to saved, live sheets.
Feedback and implementation record · Backend PR 1926Hybrid search and native customer cards extended the experience without merging access.
Backend PRs 1932, 1935 · iOS PR 113These are implementation records and documented beta feedback, not customer testimonials or measured time savings. I conceived, designed and engineered Ray from its first concept through launch and ongoing iteration. That included the portal experience, backend, retrieval and support workflows. The native iOS cards were a teammate implementation. Product examples on this page are fictional reconstructions.
Ray at Daylight
Ray brings project data, guidance and useful tools into one conversation. I’m continuing to build it around what users need.