Release notes

1.2.42 October 2026

Dev boxes whose models live in a Git repository work again - and source control is now Git or TFVC, whichever the box uses.

IDE assistant and Sofia

• Linked models are found. After a TFVC to GitHub migration the custom models sit in the Git work tree and are linked into PackagesLocalDirectory. The agent, the extractor and the index build now follow those links like real folders, so the custom models, their prefixes and the security objects are back in xpp-workspace_info, search and the index. A link that points nowhere is reported loudly at start and in doctor.
• Git is a source-control backend. On a Git box xpp-source_get_latest fetches and reports - behind the remote, local edits that would conflict, untracked objects, a protected branch - and never pulls, rebases, commits or pushes. A lapsed credential degrades to "as of the last fetch" instead of blocking. xpp-source_signin opens the Git sign-in (Git Credential Manager, including the GitHub organisation grant) and is a no-op when the credential is valid. TFVC boxes keep the previous behaviour; the tool descriptions and the workflow rules speak the bound backend's language.
• Pending changes through a link. xpp-pending_changes finds the repository behind a linked model and reports the same PackagesLocalDirectory-shaped paths in every mode.
• Doctor gains a source control section: linked packages, backend, repository and branch, credential state.

1.2.41 October 2026

The guidelines tool is easier for the assistant to ask correctly - and a wrong word no longer costs the whole pack.

IDE assistant and Sofia

• The topics are named for what a developer types. xpp-guidelines now advertises 33 finer topics - table, form, entity, extension, class, coc, security, definition-of-done and the rest - and understands the spellings assistants actually use (Tables, chain of command, unit tests, business events, approval). The extension rules for every object kind, previously reachable only by luck, have their own topic.
• A topic the tool does not know is matched by its words. "table extension" returns the table-extension rules, "extending a form" the form-extension rules; only a topic that matches nothing returns the list of topics - never the whole 100 KB pack as before.
• The assistant is told to ask by object kind. The instruction block the installer writes and the bundled tool rules say: before authoring or extending an object, ask for its kind's topic - that is where the corpus-measured shapes, element orders and method bodies are served. The activity log now records which topics were asked, so the team can see the rules are being reached.

1.2.40 October 2026

The dashboard says when each machine applied your preferences, and the assistant is told where the rules live.

Company dashboard

• "My AI preferences" says "applied", not just "reaches". Each machine under your seat now reports, with every check-in, when it last applied the dashboard's packs and which version of your preferences it holds. The card shows "applied 13:15" per machine, or "an older version" when a save is newer than what the machine has - the hour's promise, visible.

IDE assistant and Sofia

• The assistant knows the rules are on the dashboard. The instruction block the installer writes into your repositories now says that your preferences and the team's rules come from the company dashboard through the guidelines tool, and are not in that file - so a question about them is answered from the real thing rather than from whatever else the file says. Takes effect when the installer rewrites the block (a Change-settings run or a fresh install).
• The preferences file is named for what it holds. On the machine, your personal preferences now live in my-preferences.md (previously, confusingly, team-instructions.md); the old file is removed the first time the new one is written. The team's rules are in the shared cache, as before.

1.2.39 October 2026

The installer's Copilot page shows its warning and its consent box together.

Installer

• The consent box is back above the warning. 1.2.38 made the red account warning fit the "Remote review (GitHub Copilot)" page, but at the default window size that pushed the consent tick box out of view. The setup window is taller now, so the explanation, the tick box and the warning all fit. Nothing else changes in this release.

1.2.38 October 2026

The assistant knows where your preferences live, and the installer's account warning is readable again.

IDE assistant and Sofia

• "What are my AI preferences?" gets the right answer. The assistant used to answer by reading the agent's cache file, which holds the shared team rules only, and could conclude that your preferences had not arrived when they had. The guidance now says where they are (the preferences file on your machine, served by the guidelines tool, refreshed within an hour of a save) - or that none are set and where to set them - and the cache file carries a note saying the same.

Installer

• The Copilot account warning fits the page. On the "Remote review (GitHub Copilot)" page the red warning - sign in with a Business or Enterprise account - was cut off after its first line at the default window size. It is now laid out to fit, with the consent box above it.

1.2.37 October 2026

Your preferences reach a running IDE within the hour, and the dashboard says which machines they reach.

IDE assistant and Sofia

• A saved preference or Team pack arrives without an IDE restart. The agent re-reads the served rules and your personal preferences from the Company dashboard once an hour while the IDE is open; until now it read them only when the IDE started, so a change saved during the day waited for the next restart. The chat (Sofia on your machine) also keeps your personal preferences current - it used to refresh the shared rules and skip the personal ones. Clearing your preferences on the dashboard now clears them on the machine too.

Company dashboard

• "My AI preferences" says which machines it reaches. A machine receives the preferences of the seat whose token installed it - not the person signed in to the dashboard. The card now lists the live installs registered under your seat, and warns when there are none (a machine installed with a test or producer seat's token gets that seat's preferences, not yours), with the way to fix it.

1.2.36 September 2026

A question about a method's code goes to the dev VM before Sofia answers.

Sofia

• "Why does CustTable.validateWrite refuse ...?" is answered from the code. When a question names a method, Sofia asks your company's dev VM to explain it first - the code stays on that box and only the explanation comes back - and writes the answer from that. Until now she was offered the review tool and, on the small model, answered from the index without calling it. With Standard-code review switched off, or no dev VM online, the answer says so under it and gives what the index knows. The same on Teams, the Company dashboard and the installed chat.

1.2.35 September 2026

A leaner prompt for the chat, measured before it was built.

Sofia

• Sofia reads only the tool guidance for the tools she has. The chat's copy of the tool-reading rules used to carry the developer's dev-box rules too - deleting and renaming objects, project repair, pending changes, saved reports, AOS restarts, code search - which a consultant or super-user chat can never call. They are left out of the chat's prompt now (the developer's IDE assistant still reads them all). A cold question costs about a fifth fewer input tokens; nothing Sofia can do has changed.

1.2.34 September 2026

One more correction from the same evening's producer check.

Index producer

• A re-registered producer knows its own feed. Registering a producer again with a fresh token (an Update, or "Change settings") gives the install a new identity, and the published feed still names the old one - so the next publish called the seat's own feed "produced by another install" and refused to publish. The Company dashboard now tells the install which seat it belongs to, and a feed produced by an earlier install of the same seat counts as its own: it publishes, or reports "already in sync", and the Machines row names the build.

1.2.33 September 2026

One correction to 1.2.32, found on its own install.

Index producer

• The first publish reports its build too. 1.2.32 made the daily publish check report the build it published; the publish a fresh producer install runs at the end of setup goes a different way and still left the Machines row on (unreported) beside a fresh feed. The publish itself now reports, whoever runs it - the installer, the daily check or the command line.

1.2.32 September 2026

Three small things the index producer and the Members tab have been waiting for.

Index producer

• A publish reports its build. A producer that published its index (a full publish or a rebuild) now tells the Company dashboard which build it published, so the Machines row shows the build instead of (unreported) ninety seconds after a publish. Until now only the in-sync check and the recovery of a missing index reported it.

Installer

• Two companies, one environment name, two producer profiles. A producer profile is now keyed on the company as well as the environment id: a second company's producer for an environment called SIT gets its own folder and scheduled task instead of taking over the first company's. An existing producer-SIT profile stays in place for the company it belongs to.

Company dashboard

• Members are named. A seat added without a name - the owner's own seat from company registration, an invite sent without a name, a seat added by its id - takes the person's name from their Microsoft profile at their next sign-in. The Members tab and every document cover then show the name rather than the id (a name an admin typed is kept as is).

1.2.31 September 2026

1.2.30's two promises, kept by the app itself rather than asked of the model: the answer's language and "remember that ...".

Sofia

• The language of your latest question, named. 1.2.30 reminded the small model under your question; it still followed the conversation. The reminder now names the language your question was read in, and says the earlier turns do not count - English after a Dutch exchange comes back in English.
• "Remember that ..." is saved by Sofia herself. When you ask her to remember something, the app saves it before the model answers - in your words - and prints what it kept under the answer ("remember said: kept - ..."). The model can no longer say it remembered something it did not save.

Installer

• Windows 11 Smart App Control no longer blocks the installer. The setup program Windows runs from its temporary folder, and the uninstaller, are now signed with the same TSE IT SOLUTIONS LIMITED certificate as the download itself (1.2.30 showed "Error 4551: an Application Control policy has blocked this file" on a machine with Smart App Control on).

1.2.30 September 2026

Three things the acceptance walk of 22 September turned up on the small model, fixed: the answer keeps to the language of your latest question, "remember that ..." is kept and shown, and a document takes its title from the requirement you attach.

Sofia

• The language of your latest question, this time for the small model too. 1.2.29 said it once at the top of Sofia's instructions; gpt-4.1-mini still followed the conversation. The reminder now rides your question itself, so English after a Dutch exchange comes back in English - in the installed app, in Microsoft Teams and on the dashboard's Chat tab. Your question is stored and shown as you typed it.
• "Remember that ..." is kept - and you see it. Sofia calls her memory before she answers when you ask her to remember something, and prints what she kept under the answer ("remember said: kept - ..."). She no longer says she remembered something she did not save. In Teams and on the Chat tab the description of her memory speaks to you, not to a developer: your private memory, on the company dashboard and in Teams.
• A document titled by its requirement. A Functional Design Document written from an attached .md or .txt file takes its title from the file's first line, not from the words that sent it; "Functional Design Document (FDD)" alone is never a title. A super-user seat, which writes no documents, now says so instead of offering a file it cannot make.

1.2.29 September 2026

The installed Sofia app takes the new look, says what a tool refused in the tool's own words, and keeps to the language of your latest question.

Sofia

• The chat page on the new design. The same colours, type and controls as the website and the company dashboard: Sofia's avatar with her name and your seat's role line at the top ("consultant seat · read-only", "super-user seat · read-only", "consultant seat · proposes changes you confirm"), the dialogs and menus on the shared palette. Nothing moved; the Functions menu, the environment picker and the conversations list are where they were.
• What a tool refused, in its own words. When a call is refused - live data not connected on this seat, a Microsoft standard method kept out of the chat, the dev box unavailable - the tool's exact sentence is printed under the answer, with where to switch the feature on. Sofia's summary above it stays.
• The language of your latest question. Ask in English after a Dutch exchange and the answer comes back in English; the earlier turns no longer pull the language along.

1.2.28 September 2026

Sofia answers in your language, explains Microsoft standard code through your dev box instead of reading it herself on TSE's LLM, and the installer asks you to accept the Terms.

Sofia

• Answers in the language of the question. Ask in Dutch, German or Romanian and the answer comes back in that language - in the installed app, in Microsoft Teams and in the dashboard's Chat tab. Object, field, class and menu-item names stay as they are.
• Sofia introduces herself as what she is. "Hi, my name is Sofia - an AI assistant, part of TSE-Assistant." The Teams app's description says the same; your Microsoft 365 admin uploads the new Sofia app version (1.3.0) once.
• Microsoft standard code on TSE's LLM: explained by your dev box, never sent. On a company seat that uses TSE's LLM, the installed app no longer reads a Microsoft standard method's source into the conversation, even when the machine has the code. Sofia gives the location and asks your company's dev box to explain the method - only the explanation comes back. This follows your company's Standard-code review switch (dashboard, Configuration, Sofia) instead of a tick in the installer; with the switch off or no dev box online, Sofia says so and what would bring the answer. Your own custom code is shown as before, and a seat on its own AI key is unchanged.
• A clearer answer when live data is not connected. Sofia now says where it is switched on: an administrator approves the Live Data app under Configuration, Live data on the dashboard, then the seat holder signs in under Functions, Data access in the installed app. When an environment has no F&O address on the dashboard, the Data access panel says where an admin adds it.
• The rates as your provider charges them. The model picker in the installed app shows the three prices per model - input, cached input, output - with "This is exactly what Azure (or OpenAI) charges us. We add nothing."

Installer

• An acceptance step. A new page asks you to accept the Terms of Service and the Privacy notice, with both one click away, before a seat is registered or an activation code is redeemed. The version of the Terms and the time are recorded with the installation. A plain Update does not ask again.
• No wasted label build. On a company developer machine, setup no longer spends minutes building the standard label-text pack when no environment of the company publishes its index yet; it builds it on the first setup or Update after an admin ticks "Publish index".

Dashboard

• Whole milliseconds on the Activity tab. New rows record their duration as a whole number.

1.2.27 September 2026

The documents Sofia writes now say who asked for them, and a requirement can be attached as a file everywhere Sofia is.

Sofia

• Every document names its author. The cover of a design or FDD Sofia writes - the web page, the Word download, in the dashboard, in Teams and in the installed agent alike - now carries a "Prepared by" line with the seat holder who asked for it, as "Jane Doe (via Sofia / TSE-Assistant)". The installed agent shows it when the seat has a name on the company dashboard; a seat without one keeps the cover as before.
• Attach a requirement in Microsoft Teams and in the dashboard's Chat tab. A .md or .txt file attached to a message (up to 400 KB, the same as the installed agent) goes to Sofia with your words - or alone, which asks for an FDD of it. In Teams, a Word document or a PDF is named and not read; save it as text first. Your Microsoft 365 admin uploads the new Sofia app version (1.2.0) once so Teams delivers the files.
• The Documents tab shows the author and the delete button from the first moment. Opened straight from a link, the tab could show the author as a code and hide the delete button until a keystroke in the search box. It now completes itself as the account's data arrives.

1.2.26 September 2026

Two additions on the company side; the installed agent is unchanged.

Sofia

• Word (.docx) downloads for the documents Sofia writes in the dashboard and in Teams. Every design or FDD Sofia writes for your company account can now be downloaded as a Word document from the dashboard's Documents tab and from the answer itself in the Chat tab - the same Microsoft FDD / TDD template cover, headings and tables your installed Sofia already produces. The installed agent's own .docx export is unchanged; its renderer simply moved into the shared component.
• Sofia in Microsoft Teams for company seats. Your Microsoft 365 admin adds the Sofia app to your organisation once, and every consultant or super-user seat holder can chat with Sofia in a personal Teams chat: the same answers as the dashboard's Chat tab, the same published environment, no sign-in step (Teams already knows who you are), no software on the machine. A design or FDD arrives as a card with buttons to open it on the dashboard or download it as Word. Three commands: /sofia env, /sofia new, /sofia help.

Dashboard

• Create producer seat works for every company account, and a failed seat write now answers at once instead of timing out. On a second company account whose environment carried the same name as another account's, the Environments tab's "Create producer seat" hung and ended in a gateway timeout. The producer seat's identity is now per account, and any seat write the service refuses comes back as a message on the page immediately. Existing producer seats keep their identities; nothing to redo.

1.2.25 September 2026

Internal only - nothing you use changes.

Sofia

• The last pieces of Sofia's reasoning moved into the shared component: the model connections, the instruction packs' loading, the naming values drawn from your environment, the memory rules. The installed agent uses them exactly as before; the coming hosted Sofia (the dashboard's Chat tab) is built on the same pieces.

1.2.24 September 2026

Mostly internal; one small correction to design answers.

Sofia

• A design answer names things the way your environment already does. On the small model, a "how should we build ..." answer once invented a naming convention (a number after the prefix) that your own objects do not carry. The design rule now says that what follows the prefix copies the shape of your existing objects, and nothing the evidence does not show.
• Internal: Sofia's instructions are composed in the shared component. The persona, the seat's rules, the coding standards, the environment facts and the memories are assembled by the same code the coming dashboard Chat tab will use. Nothing you see changes.

1.2.23 September 2026

One correction from the 1.2.22 check.

Sofia

• A design answer is always written for you. On the small model, a "how should we build ..." question could come back as a block of JSON - the right names and properties in the wrong form. Sofia's design rule now says the form (headings, short lists, prose), and any answer that still arrives as bare JSON is rewritten as prose in one extra step before you see it.

1.2.22 September 2026

An internal change only: nothing you use looks or behaves differently.

Sofia

• Sofia's reasoning moved into a shared component. The part of Sofia that classifies a question, gathers the evidence, runs the tools and writes the answer (and the design document) now lives in one package that the installed agent uses today and the dashboard's coming Chat tab, and later the Teams and Slack apps, will use as well. Same questions, same answers, same costs - one place to improve them for every way of reaching Sofia.

1.2.21 September 2026

Four small corrections from an independent test of the developer seat.

IDE assistant

• A scaffolded table no longer writes a default. xpp-scaffold_object kind:table omits SaveDataPerCompany (Yes is the serializer's default and the served standard says never to write one), so the new table reads like a product table.
• One population per topic. xpp-guidelines topic:element and topic:element-order, and label and labels, now return the same rules; the topic list advertises element-order and labels, as the tool description does.
• Tidier topic slices. A section header written before the next rule no longer trails the previous rule into a topic's output; the reference-tier count in explain:true matches the one in the no-topic response.
• The TDD tool's description names the thirteen template sections it actually serves.

1.2.20 September 2026

Small things from the last two weeks of testing.

Sofia

• No more "conversation limit reached". Sofia keeps up to a hundred conversations per session (was twenty) and, at the bound, quietly drops the oldest one you are not in instead of refusing a new chat.
• One wasted round less on the strong model. The coding standards are read for design and naming questions only; a process, message or field question no longer spends a round on them.
• Rate limits are honoured to the second. When the LLM provider asks Sofia to wait, its exact wait time now reaches her, so the retry lands after it rather than on a guess.

Dashboard

• A complimentary account no longer shows a "Renews" date left over from an earlier subscription.

1.2.19 September 2026

The prefix reaches Sofia's design answers.

Sofia

• Your primary prefix, for real this time. 1.2.18 wrote the prefix into Sofia's design rule, but the chat's own instruction pack was not passed through the same rendering as the served packs, so Sofia read the rule's placeholder rather than your prefix. The chat pack is now rendered with the same values; a design answer names every new object with your primary prefix written out.
• The standards Sofia reads for a design start with the object kinds your question names (the table, the form, the security artifacts) before the ones the design implies.

1.2.18 September 2026

Design answers carry your primary prefix; the completed design document has no repeated sections.

Sofia

• Your prefix, written out. A design answer names every new object with your organisation's primary prefix - no "<Prefix>" placeholders, no choice between your prefixes left to you - and the standards it reads cover the object kinds your question names (a table and the form and the security artifacts), four kinds rather than three.
• No repeated sections. When Sofia asks the model to complete a design document, it asks for exactly the missing sections and drops any section the model rewrites on top of one already there; a section headed "Reporting, integration, and audit" now counts as the Integration section, so it is not asked for again.
• Plainer answers. Sofia no longer tells you to run one of her tools - she says what to check; and an answer about a quoted message names the parameter fields her look-up matched rather than saying no field carries the message's wording.

1.2.17 September 2026

Design questions researched first; a cheaper design document on the strong model.

Sofia

• "How should we build this?" A design question - a new table, form, field, data entity, menu item, security artifact, extension, batch, report - now runs its research before the model answers: the measured standards for each object kind the question needs (the properties, their order, the naming) and the objects your organisation already has in that area, so the answer carries your prefix and reuses what exists instead of proposing a duplicate.
• The strong model's FDD costs less. After Sofia's own look-ups, the model gets two rounds of further reading before it writes, not four or five; the document is complete either way.
• Leaner guidance. The chat's instruction pack keeps how to answer each kind of question and drops the step-by-step tool recipes the research step made redundant.

1.2.16 September 2026

The design document is completed when the model stops short.

Sofia

• Every section, every time. When the model ends the functional design before the template's last sections (the default model tends to stop after Solution design), Sofia asks it once more for exactly the missing sections and appends them, so Security requirements, Integration, Reporting, Migration, the validation scenarios, the open questions and the acceptance criteria are there - as "Not applicable" lines where they do not apply.
• Tidier assessment. The classification table sits under the model's own Solution assessment heading instead of adding a second one, and a missing confidence is set from the evidence the document cites rather than always "low".

1.2.15 September 2026

The design document is asked for as a document.

Sofia

• A document every time. Sofia now asks the model for the functional design as the document itself - the title, the Solution assessment, the Evidence / References and the template's sections in plain markdown - with the classification in a small block at the end that Sofia checks and removes. The previous JSON envelope was answered in a different shape on each try by the default model; a document is what a chat model writes without being told twice. A reply that still comes back as JSON is rendered as before.
• Untitled or unclassified replies take the document's title from your request and say "needs_review" rather than showing nothing.

1.2.14 September 2026

The design document renders whatever shape the model hands back.

Sofia

• No raw JSON, on either model. On the first 1.2.13 test both models returned the design as structured JSON (sections as objects, the Step-Id table as rows) instead of a markdown document, and one of them reached the chat unrendered. Sofia now turns such a reply into the document - the template's sections as headings, the rows as tables - and the instructions to the model say plainly that the drafts are text. A document whose validation section is titled "Test cases" or "Testing" is recognised as such and not given a second one.

1.2.13 September 2026

Design documents in the shape Microsoft's own template uses - and as Word files.

Sofia

• The functional design follows the Microsoft FDD / TDD template. Sofia's FDD now carries the template's section names and tables: Scope; Description of business process as a Step-Id table (one row per step of the standard process, with the screen or action, what it writes, and your organisation's extension at that step); Functional design as numbered FD rules the validation scenarios and acceptance criteria cite; Solution design; Security requirements as a role × entry point × access matrix; Integration; Reporting and analytics and Migration when the requirement touches them. Sofia's evidence tiers, options considered and validation scenarios stay as their own sections.
• Download as Word. Every design document now offers download .docx next to open document (print / save as PDF) and download .html: the template's cover (project, customer, environment, prepared by, date, version - the points of contact and the change sheet left for you to complete), Word headings and real tables, ready to file with the customer.

IDE assistant

• The technical design too. The TDD's sections take the template's names and devices where they apply: Scope (with the FD rules it implements), Description of business process opening with the Step-Id table, Table structure and field properties (per table: Field, EDT / type, Label, Mandatory - the template's "Architecture solution design" in F&O terms), a Forms and user interface section, and Security requirements as the role matrix.
• xpp-save_report writes the .docx next to the .md and the .html it already wrote, and returns its path.

1.2.12 September 2026

Any language, all the way down; your objects named on every process answer.

Sofia

• No language is special. The document title of an FDD is taken from the request in the language it was written in; role names, field labels and message texts are compared with the published label text using the same rules for every alphabet and every diacritic; a field named in your language is also looked up by its English name in the index. Nothing in Sofia lists languages - what decides is the label text your organisation publishes.
• Your objects, named unasked. A process answer now carries your organisation's extensions on each step and its own journals, posting classes and parameters in the area by their exact names, on the default model as well as the strong one.

1.2.11 September 2026

The 1.2.10 retest on both seats and both models, and the three things it still showed.

Sofia

• The FDD always starts from the evidence. When you ask for a Functional Design Document, Sofia runs the FDD tool herself - the requirement classified against your environment, the standard objects behind it, your organisation's customizations and own objects - and then its recommended look-ups, before the model writes a word. On the default model the document had occasionally come back as the raw contract when the model skipped that step; it cannot any more.
• A field question knows its table. "What does the Credit limit field on the customer mean" now looks in the customer table first (the model names the table, Sofia verifies it) and follows the field with the objects that use it - on every seat, not only when the model happened to name the table.
• Your objects, by name. A process answer names your organisation's extensions and its own journals, posting classes and parameters exactly as they are called, rather than saying that customizations exist; a customizations question looks at the objects you named before the process's default ones.
• Long documents fit. The strong model's full FDD had once been cut off before the end of the document; the answer limit is now four times higher, and if an answer is ever cut off Sofia says so instead of showing a broken document.

1.2.10 September 2026

What the first live run of "research first" found on both seat kinds and both models, fixed.

Sofia

• Roles by the name you know them by. "A user with the roles Accounts receivable clerk and Accounts payable clerk - can they delete a customer?" is now answered: the role names are resolved through the published label text (in any language your labels are published in), and a near miss gets a "did you mean" that works on the real role names.
• Approvals are approval questions. "Who can approve a purchase order?" is answered from the workflow (the assignment decides who; security is the ability to act) on the default model as well as the strong one, with the document's own entry point instead of the confirmation action.
• The right parameters table. A quoted message or a field question looks in the parameters table that governs it (the credit-limit message: Accounts receivable parameters, then Sales parameters), filtered by the message's own words; no table name is ever invented from a word.
• "Where does the system use it" comes with the answer. A field question follows the field it finds - recognised by its label ("Credit limit" is CreditMax) or its name - with the objects that reference it and its extended data type, so the answer no longer needs eight rounds of searching.
• Your own objects, named. The resolved process now lists your organisation's journals, posting classes and parameters in the area from one direct query, and lists your extensions first on every step (Microsoft's own feature models after them); the result is kept whole for the answer.
• The FDD inspects what the requirement is about. The objects you or the requirement name come first, then the requirement's terms, then your organisation's objects in the area - the process's other steps no longer use up the look-ups.
• Quieter, in your language. The look-ups already made are not repeated; an answer is written in the language of the question; a busy minute on TSE's LLM is waited out (up to a minute, honouring the host's retry-after) instead of failing over to your own key; the environment overview is computed once per index; an FDD asked on a super-user seat gets the process evidence; a refused new chat is said in the chat instead of a browser dialog.

1.2.9 September 2026

Sofia researches before she answers - for every kind of question, in any language.

Sofia

• Evidence first. Before answering, Sofia classifies the question - a process, who can do something, an approval, the customizations around an area, a quoted message, a field - and runs the look-ups that kind of question needs in your environment: the process resolved step by step with what each step writes and who can perform it, the security coverage of the action's entry points, your organisation's own objects around the area, the label behind a message and the parameters that govern it. The answer is written from those results; the trace shows every look-up. The same on the default model as on the strong one.
• Any language. The classification is done by the model, so a question in Dutch, German, Romanian or French is understood the same way; a quoted error message is searched in its own language when your labels are published in it, and in English otherwise.
• Processes resolved in your environment. "How does a sales order become an invoice" now answers with the steps as they exist here - the screens, the posting actions, the journals, the stage the order reaches - and, attached to each step, what your organisation changed and the journals, posting classes and parameters of your own that sit in the area. Ten standard processes are seeded (sales order, quotation, free-text invoice, customer payment, purchase order, purchase order approval, vendor payment, production order, transfer order, inventory journal); every seeded name is confirmed against your index and dropped when absent.
• The FDD carries the seed's objects as known objects, and the objects the requirement names are now the first ones inspected; a qualified provenance marker ("[verified by ...]") is read as the marker. The process-map article names the confirmation and purchase objects as they really are and states where "unpaid" lives (the open customer transactions, not a status on the invoice).

1.2.8 September 2026

Sofia gathers the FDD's evidence herself.

• The evidence is read, not requested. Right after the FDD tool answers, Sofia runs its recommended look-ups on your behalf - the process map, the structure of the standard objects the requirement touches (one per business term, the table that decides the requirement first), the changed methods of the customizations on them, your organisation's own objects in the area - and writes the document from those results. On the default model this replaces a document written after a single call. Every look-up shows in the answer's trace.
• Fields are verified, not assumed. A field or method is marked [verified] only when a look-up in the conversation listed it; "unpaid" and "open" amounts are traced to the open-transaction and settlement tables, never to a status flag on the invoice journal.

1.2.7 September 2026

The Functional Design Document now looks at both sides of your system before it recommends anything: the standard process behind the requirement, and the code your organisation already built around it.

Sofia (consultant seats) and the IDE's FDD tool

• The standard process, found for you. From the requirement's own words ("sales order confirmation", "customer invoice", "credit limit", "vendor payment", ...) the FDD tool names the standard objects behind the process - the posting actions, journals, parameter tables - and keeps only the ones that exist in your environment. No more guessed method names.
• Your own code, found for you. The tool lists the customizations already sitting on those objects (with the methods they change) and your organisation's own objects in the same area, so the design reuses or extends what you have instead of building it twice.
• Sofia reads the custom code. Where the box has the packages folder (an individual consultant's dev box, the developer seat's IDE), Sofia reads the changed methods and says what they do; on a company seat she designs from the customization's structure - the wrapped method and the members it adds - without remarking on source. Microsoft standard code is never invented - the real names come from the index, the behaviour is marked to confirm, or read through standard-code review where it is enabled.
• A better document. Standard configuration is considered first and its shortfall stated; the FDD now carries "Standard behaviour today", "Existing custom code in this area" and "Options considered" (configuration only / extend the existing customization / a new extension, with trade-offs) before the recommendation. An FDD question gets fourteen tool rounds instead of eight.

1.2.6 September 2026

The consultant seat, tested on the default model: the Functional Design Document arrives as a document, designs are named with your organisation's prefixes, and Sofia introduces herself as a consultant's assistant.

Sofia (consultant seats)

• The FDD is a document you save as PDF. "Write an FDD for ..." used to come back as the raw structured result on some models (a wall of JSON with the document inside it). Sofia now writes it as one document - title, solution assessment, evidence, the short and the full draft, with the Functional Validation Scenarios section always present and the classification rules enforced - and the answer carries open document (print / save as PDF): the same styled report the developer seat's TDD produces, opened in a tab for Ctrl+P, Save as PDF (or downloaded as .html). She also confirms the standard process objects (the confirmation and posting actions, the journals, the parameter tables) before writing, instead of guessing a method name.
• Your prefixes, not a placeholder. When Sofia designs new objects (a setup table, a form, its security), the names now carry your organisation's enforced prefix (or the prefix your custom objects already use) - the same values the IDE rules render - instead of a generic "YourMod".
• A consultant's greeting. Sofia's introduction on a consultant seat names what the seat does: FDDs from a requirement, the customizations and standards of this environment, environment compare, live data (read-only until you connect it).
• Sofia no longer spends a round on a tool that is not on the seat.

1.2.5 September 2026

Two refinements from the 1.2.4 retest: when a name you typed is a label rather than the system name, Sofia takes the suggested match and carries on instead of asking you to confirm; and "who can post a customer invoice" covers both standard routes (sales-order invoice and free-text invoice) in one answer.

1.2.4 September 2026

Sofia, tested question by question on the default model: the answers that used to die at the tool limit now arrive, and she knows the standard process behind a business question before she starts searching.

Sofia

• Every question gets an answer. When a question used up Sofia's tool budget, the final answer was requested in a way the OpenAI-compatible hosts reject - so on TSE's LLM the user read "reached the tool-call limit" (or a complaint about their own key) after eight rounds of good work. Fixed; and if the final answer still cannot be produced, Sofia now says why.
• A busy minute no longer switches routes. A rate-limit pause from TSE's LLM is waited out and retried instead of falling to the seat's own key; when both routes fail, the message names both.
• Process maps. A new knowledge topic hands Sofia the standard objects behind order-to-cash and procure-to-pay - the screens, the posting actions, the journals, the parameter tables, the credit limit check - so "how does a sales order become an invoice" is answered in steps instead of searches.
• Four methods, one per question shape: a tool budget with a plan; process questions (knowledge first, then confirm); "what customizations exist around X" (the custom models, then the standard objects they extend - never a search for English words); a quoted error message (find its label, then the module's parameters); "who can approve" (the workflow's assignment decides, security is the ability to act).
• Activity digest. Sofia's own tool calls now count - the digest no longer reports "no tool activity" on a chat seat. The empty-chat hint no longer tells a seat on TSE's LLM to enter a key.

1.2.3 September 2026

Sofia answers "who can do this?" from the action itself.

• Who can post, approve, release. Sofia now locates the menu item behind the action (the posting item of a sales-order or free-text invoice, the form behind an approval), reads the privileges, duties and roles that grant it, and walks a privilege up to its duties and roles before answering - instead of checking the underlying table and reporting that nothing was found. When several routes exist she answers the standard one and names the others.

1.2.2 September 2026

The reference standards now cover the whole authoring surface, and the write gate checks every AOT object against the measured element order - the class of defect the compiler never reports.

Standards, complete

• The reference tier grew from 44 to 162 rules - table method bodies, extension object shapes, form patterns and controls, entities, views, queries, menus, security, features, SysOperation, reports, approval workflow, labels and documentation, test layout and the Acceptance Test Library - each with the measured numbers and a standard exemplar. Served by a finer topic only (table, form, entity, security, ...), so the default call is unchanged; an area-wide call now points at the finer topics instead of returning everything.
• The write gate enforces the measured element order for every object kind. The serializer silently drops a property written in the wrong place (a FeatureClass after Label is a field that is always visible, with no build error). Until now the gate checked form datasources only; it now checks tables, fields, indexes, relations, EDTs, enums, forms, controls, entities, menus, privileges and every other kind - 213 element paths measured on the standard application - and names the offending pair and the measured order in the denial.

1.2.1 September 2026

The standards your tools follow were measured against the standard application itself - every AOT object on a live D365 F&O box - and the parts that were wrong are fixed. Deeper reference standards are now a topic away, for the IDE assistant and for Sofia alike.

Standards, measured

• Corrections. Seventeen rules the assistant used to follow did not match the product (a test assertion that does not exist, a business-event registration class that does not exist, an attribute Microsoft writes on 1 of 181 services, "never enable an entity for both OData and Data management" when most standard entities do). They now say what the standard application does, with the numbers.
• Reference standards by topic. Element order per object kind (the serializer silently drops an out-of-order property), the canonical shapes of entities, menu items, privileges, feature classes, batch jobs and reports, and a definition of done for a setup table, a document, a batch job, an entity and a feature-flagged change - served only when the assistant asks for that topic, so nothing gets slower or costlier by default.
• Sofia receives the same served standards as the IDE - until now only the bundled copy reached the chat.

1.2.0 September 2026

Two Sofia improvements on every machine, and the platform now writes to you: seat invitations, a welcome mail when your subscription starts, and a warning before Sofia's credit runs out.

Sofia

• A plain sentence when your own key fails. Instead of the provider's raw error, Sofia says which provider refused, what happened (a refused key, no credit left, a model this key cannot use, a rate limit, the host's own trouble) and where to fix it: Functions › LLM Key. The host's own words follow after "said:". Answers on TSE's LLM are unchanged.
• The page keeps itself current. An open Sofia checks its state every minute and when you return to the tab, so a route your admin switched, a top-up that landed or credit that ran out shows without asking a question or reloading. It never interrupts a running question or an open dialog.

Mail from TSE-Assistant

• Seat invitations. Inviting a user under Users & Seats now sends them a mail from no-reply@tse-assistant.com: who invited them and the steps for their seat. Resend invite sits on a pending seat's row.
• Welcome mail. When a company subscribes, its owner and admins receive what was bought, the renewal date, the seats in total, the Sofia welcome credit and how to invite people.
• Low-credit warning. The owner and admins are mailed once when Sofia's credit falls low and once when it runs out, with the top-up link.

Sign-in and reliability

• Microsoft's sign-in prompt for TSE-Assistant Live Data now names TSE IT SOLUTIONS LIMITED as a verified publisher. Your Entra admin approves a verified app; users in tenants that allow it can consent themselves.
• Subscription events from the payment platform are acknowledged at once and mail is sent afterwards; an event interrupted mid-way is completed on the next retry rather than reported twice.

1.1.3 September 2026

Sofia can now run on an LLM that TSE-Assistant hosts - no API key to bring - and this release names what that costs, who decides, and what happens when it is off.

Sofia on TSE's LLM

• No key needed. When your admin switches it on (Configuration › Sofia on TSE's LLM), consultant and super-user seats ask Sofia on TSE-Assistant's own LLM, metered against the company's Sofia credit. Your own key stays as the fallback and can still be used at any time.
• Two models, at cost. gpt-4.1-mini on Azure OpenAI in the UK South region - low cost, good for lookups, explanations and everyday questions - and gpt-5.6-terra on OpenAI (US) for complex X++ reasoning. Metered at the provider's list price with no mark-up; the rates are shown in Sofia, on the Billing tab and on the pricing page.
• Your admin decides, you choose. The admin allows one model or both and sets the default; if both are allowed, pick yours under Functions › LLM Key on each machine. Every answer line now says what it cost and which model answered.
• Credit in the open. The chat says how much credit is left, warns above the composer when it is running low, and says plainly when the company's Sofia credit is used up or the admin has switched TSE's LLM off - every seat then brings its own key, exactly as before.
• Welcome credit. Every consultant or super-user seat a company buys brings a one-time Sofia credit; admins top up any amount from the Billing tab.

Company dashboard

• Configuration › Sofia on TSE's LLM: enable for the tenant, allow models, set the default - with where each model runs and its rate. Turning it off greys the choices and says what seats will see.
• Every Configuration section is tagged Admin or Everyone, so it is clear who can change it.
• Billing › Sofia credit: credit left this period, purchased credit, spend per model and per seat, a low-credit warning, and the rate card.
• Live billing: subscriptions, seat changes, top-ups and invoices now run on the production payment platform.

1.1.2 September 2026

A small release, one day after 1.1.1, so that every install learns about the new update notices at once.

Updates are announced everywhere

• Your IDE assistant - Copilot in Visual Studio, VS Code, Claude Code, Cursor - is told once at the start of a session when a newer TSE-Assistant is available, with a link to these notes. It carries on working; the update is yours to schedule.
• The company dashboard shows one quiet line under the tabs naming the release and how many machines are behind; the × hides it until the next release. It turns red only when a machine is below the minimum supported version.
• Sofia and super-user installs now report their version too, so the Machines tab is complete.

Company dashboard

• A deactivated seat's installs move to the old-installs group at once ("seat deactivated") instead of counting as live machines for 30 days.
• The live-data reminder is a plain "Action needed" panel instead of an orange box.

Index producers

• A daily check that finds the published feed already current now still reports in, so a healthy producer's row on the Machines tab stays fresh.
• The daily task - and the sign-in relay task on every developer machine - now run on battery power and catch up a start the machine slept through. Laptops used to skip both silently while unplugged.

1.1.1 September 2026

The first numbered release since 1.1.0 (July). Everything shipped between the two is included; the highlights:

Index producers (SIT / UAT publishers)

• The daily 12:00 refresh now runs whether or not anyone is signed in to the producer machine — no password to type, nothing stored. Existing producers pick this up on their next Update.
• A producer whose index went missing rebuilds it on its own; a producer that is not allowed to publish (deactivated seat, unpublished environment) says so first instead of rebuilding for nothing.
• "Already in sync" now checks whose feed the server holds — a second producer for the same environment is named, not silently overwritten.
• The installer prints a timing summary at the end of every run, so a slow install explains itself.

Sofia (consultant and super-user seats)

• Standard Microsoft label text is now searchable on branch-published environments, in the languages your admin ticks under Configuration › Label text languages. Sofia refreshes on her own when a new pack is published.
• Live-data sign-in is offered, not forced: one dismissable prompt per environment; a sign-in started for one environment covers the others.
• A question typed while an environment is still loading is held and sent the moment it is ready; picking an environment twice no longer errors.
• Sofia knows which environment and build she is on, and says so; a second Sofia launch opens the running one instead of failing.
• Refusals name their cause — a deactivated seat, a suspended subscription, an environment outside the seat's scope, an ended trial.
• A newer installer is announced at the top of the chat.

Company dashboard

• New Configuration tab: object-name prefixes to enforce, label text languages, live-data approval, team instructions.
• Change seats from the Billing tab; cancellations scheduled at Paddle are shown; the invoice list shows invoices only.
• Machines: seats named by their label, "Uninstalled" and old installs listed automatically, a "modified install" flag when an install's files do not match the published build, an "index missing" flag when a producer's rebuild keeps failing.
• Storage tab: what each environment's published index costs, retired feeds and their purge date, the label-text pack.
• Environment scoping of a seat is enforced everywhere the seat pulls data.

Installer

• A Seats on this machine page lists every seat installed on the box with its live status before you choose Update / Change / Add.
• An older installer asks before replacing a newer install; adding a seat that is already installed here is refused with the right advice.
• Producers can be retired one at a time (retire-profile), without uninstalling everything.

Licensing and billing

• Individual licences renew on every start when online; a refunded or charged-back purchase is revoked everywhere and its subscription cancelled.
• Complimentary accounts are shown as such; trials and their end dates are visible on the dashboard.

1.1.0 July 2026

The first company-dashboard release: seats and registration tokens, per-environment published indexes for consultant and super-user seats, the signed double-click installer, Paddle billing with a 30-day company trial and a 16-day individual trial.