Connected systems
What information comes in, what goes out, and what the business notices when each connection is unavailable.
What information comes in, what goes out, and what the business notices when each connection is unavailable.
Microsoft 365 mailboxes
| What comes in | Mail from enrolled Flowtech mailboxes: subject, body, sender and recipients, date, and all attachments — including files nested inside forwarded messages |
| What goes out | Replies sent from FlowOS. Quotations are issued as a PDF and sent from the salesperson’s own mail; sending them from FlowOS comes next. The shared office mailbox is the reply-to even when the engineer is the from |
| Which side is authoritative for inbound | The mailbox. FlowOS holds a copy of what was received |
| How current | As current as the last successful delta. Each mailbox has its own cursor |
| When unavailable | Sync records the error and consecutive failures. Everything already held stays fully workable |
The mail body is taken in its formatted form and converted here, because letting the mail service flatten it loses table structure — an enquiry listing three instruments in a table would otherwise arrive as one value per line.
Sent Items: the internet message id of mail FlowOS sends is recorded. Without it, delta sync would ingest our own quotation as a new inbound document. Combined with scoping the delta to Inbox.
Entra ID
| What comes in | Who the person is, for Microsoft sign-in |
| What FlowOS owns | Office, roles, grants, password invites. Office is not read from Entra |
| When unavailable | Microsoft sign-in fails. Password accounts still sign in. Existing sessions continue until they expire |
The language-model service
Used for the reading that cannot be done by rule. Today that is typing each message, naming an enquiry’s categories and reading what it asks of the offer. An enquiry’s contact is read by the contact reader below, and what requirement gathering sends is under Requirement gathering.
| What goes out | The subject, the new and forwarded text, and attachment names of each message; for an enquiry’s categories, the subject, attachment names, what the client wrote and an excerpt of each converted attachment (its name, the repeated values of its item tables and the rows that state a type, headings, table column names and up to five lines per category that name a product, at most 8,000 characters in all), and for its asks, only the client’s lines that may ask something, each with the line above it. What the client wrote can come from quoted history, when a colleague’s reply carries the client’s email below it. When no client is found, such as a colleague restating a request, the email’s own new, forwarded and quoted lines are read as the client’s. Never whole attachments, and never quoted history for typing |
| What comes in | The message’s type and whether it revises something; for an enquiry, which product categories it asks for and how likely each product type in them is, and for each line sent about its asks, which kind of ask it is, if any |
| Which side is authoritative | FlowOS. Nothing is stored on the other side that we read back |
| When unavailable | Typing a message is tried again — the message stays out of the inbox while it is retried, and one that still cannot be typed goes to Needs Review. An answer that is only unsure sends the message to Needs Review for a person to type, unless it links by one of our quotation numbers (R7). An enquiry’s categories are named from the words kept for each category alone, and a line whose words name an ask is kept as that ask, unconfirmed. Other work continues |
The service is TypeSafe’s Jev, reached directly and fixed to release 1.14, so a new Jev release is taken up only when FlowOS is updated to it. Customer enquiry text is sent to it and kept under TypeSafe’s default terms; where it is hosted, and under what agreement, is a question for the business.
The contact reader
A second language model, OpenAI’s GPT-6 Luna reached through the Vercel AI Gateway, splits a client’s signature block into name, designation, company and address.
| What goes out | The client’s signature block, up to 15 lines, and, when their email arrives forwarded or quoted below a colleague’s reply, its header lines (From, sent time, To, Cc, subject), less any line naming a Flowtech address. A Cc line can name the client’s colleagues. Nothing when no client is found. Never the body, attachments or the rest of the quoted history |
| What comes in | Name, designation, company and address, each kept only if the block itself says it |
| Which side is authoritative | FlowOS. The email address, phone numbers, GSTIN and PIN are always read by rule |
| When unavailable | The contact keeps what rules read and is marked as read by rule only, and other reading continues. When the service is only limiting how often it is called, the enquiry’s whole reading waits a minute and runs again |
Client names, phone numbers and addresses are sent to this service, which routes each call to a provider hosting the model (OpenAI and Amazon Bedrock today). No zero-retention agreement covers it. Its retention terms are a question for the business, as for the language-model service above.
The document reader
Converts attached documents to text on the deployment, keeping tables as tables. It has no character recognition: a scanned PDF is listed as needing it, and is handed to the picture reader where that is allowed. The scanned pages of a typed PDF are marked where they stand and handed over the same way.
| When unavailable | A document it cannot convert, or that takes more than 30 seconds, is listed as not read with the reason. Everything else still converts |
The picture reader
The same model, on the same service as the contact reader, transcribes a picture attached to an enquiry, such as a photographed datasheet or bill of quantities, into text, keeping tables as tables. It transcribes a scanned PDF attached to an enquiry the same way, and the scanned pages of a typed one.
| What goes out | Each picture (JPEG, PNG, WebP or GIF) attached to an email typed as an enquiry, sent whole, after the email is typed as an enquiry and only while model calls are on. Each scanned PDF attached to such an email, sent whole, when every mailbox the email was delivered to is one requirement gathering may send, which is the test mailbox until a zero-retention agreement is recorded. The scanned pages of a typed PDF attached to such an email, on the same terms, each run of them as a PDF of only those pages; never its typed pages. A picture or scan already read for an earlier enquiry is reused, not sent again. For a later email from a client that the change reader reads, each picture pasted among the client’s own words (JPEG, PNG, WebP or GIF, at least 200 pixels long and 20 high, at most five), sent whole, only while model calls are on and only when the change reader may send that email to its model, which is mail to the test mailbox until a zero-retention agreement is recorded. Never a picture or scan attached to any other email, never another picture the email’s body shows, such as a signature logo or one in our quoted offer, and never the email’s text |
| What comes in | The picture’s or scan’s text, with [illegible] where a word or number could not be read with certainty, marked as read from a picture or from a scan so later reading can weigh it. A transcription that stops before the end of the document is discarded |
| Which side is authoritative | FlowOS. Nothing is stored on the other side that we read back |
| When unavailable | The picture or scan is listed as not read, with the reason, and the rest of the enquiry is read. A picture in a client’s later email is named among what the change reader could not read, and the rest of the email is read. When the service is only limiting how often it is called, the email waits a minute and runs again |
Pictures and scans can show names, prices and drawings. This service’s retention terms are a question for the business, as for the contact reader.
Requirement gathering
Gathering an enquiry’s requirement lines uses both services. The model the contact and picture readers use is sent the email’s text and its attachments, to split the enquiry into lines and read each line’s values. The language-model service is then asked which library fluid or menu option a wording means, and checks each value read against the lines of the enquiry it was read from. For a fluid wording holding a chemical formula the library cannot match, the first model is sent only its formulas and the joins between them, and asked to name the chemicals; each wording is sent once. Until a zero-retention agreement covers these models, gathering runs only for mail delivered solely to the test mailbox. It starts by itself for an enquiry’s first email while requirement gathering is switched on, and a Developer can process one email again from Mail Debug, which gathers it afresh. Requirement gathering has what each step sends.
Model call tracing
Each call to the model behind the contact reader, the picture reader and requirement gathering can be recorded in Langfuse, a tracing service, in its Japan region, so a wrong reading can be followed back to what the model was asked and what it answered. It is off until Langfuse is set up for an environment.
| What goes out | For every such call: which reader made it, the model, how long it took, how many tokens it used, whether it failed, the id of the email it was made for, the step of processing that made it and which try of that step it was, the id of the enquiry when the step works on one, the version of FlowOS that made it, and the version of the requirement-reading instructions. After each step: whether it succeeded or failed, and the email’s status then, such as Needs Review, filed under the email’s id. After requirement gathering, three counts for the email: how many pressure, temperature or flow figures the reading had copied into a second row (R129), how many of its lines still hold figures out of order, such as a minimum above the maximum, and how many figures a line’s own row labels differently from the reading model. No error message is sent. For mail delivered solely to a mailbox requirement gathering covers, which is the test mailbox today, also the text the model was sent and the text it answered. No attachment file is ever sent: where a model was given a file, the record keeps the text beside it and a marker in the file’s place. A picture’s or scan’s transcription counts as text, under the same rule |
| What comes in | Nothing. FlowOS never reads a trace back |
| Which side is authoritative | FlowOS. A trace is a record for finding a fault |
| When unavailable | Reading carries on, and the calls of that time are not recorded |
Langfuse keeps what it is sent. The rule on text above therefore stays as it is when a zero-retention agreement is recorded for the models. Calls to the language-model service are not recorded.
The ERP of record
| What goes out | Confirmed sales orders, after PO-vs-quote verification |
| What comes in | Acceptance, rejection, and reconciliation state per attempt |
| Which side is authoritative for stock and dispatch | The ERP |
| When unavailable | The handoff row stays in the queue and can be retried. Postgres is truth; the queue message is transport |
The defect tracker
The floating Report a problem control sends a defect with the page they were on and their browser details. When unavailable, they are told it did not send. Nothing else is affected.
Not connected
| System | Position |
|---|---|
| Stock / dispatch / invoicing | Stay in the ERP after handoff |
| IMAP as a second mail path | Mail comes from Microsoft 365 Graph |