Recording notes for the day. Spent over an hour working on some AI training inside of adilas - see attached. As part of the training, I went over some of the older training sessions and then did some stuff on help files and general file structure within the system.

Meeting with the Nxtlinq guys. They wanted a way to get and show the error messages in the chat bot. If the page is able to navigate to the correct page, all is well. If not, meaning it throws an error, they want a way to get at those error messages. We also talked about helping to make better error messages to show what to do to fix things (make things more intuitive). They gave us an update and have optimized the memory functionality of the AI agent. There are now a number of users that can affect the global context (actual AI training) within the system.

After the meeting, Ted, Thomas, Josh, and I were talking about 3 buckets for our customers - low hanging fruit (those who are using it), those who could use it but aren't, and those who don't want to use AI. Ted was really pushing for us to try to get the people actively using it, even while we are training it. His focus is the commercialization process. We talking about the need for data and feeding the AI agent. After that, we were looking at AI data and logs, encouraging people to keep going and ask for more (what else would you want from the AI agent - figure out what the customers are wanting). Somewhat of an outreach plan to help commercialize things to our customers.

Back working on the add bulk PO lines items page. I copied the code from the parts homepage. I then had to go through it and strip it out a bit. Got the search and display page done. After that, I started working on the submit or action page for the bulk add PO line items page. Lots of validation and looping. I pushed my changes up to the correct branch in the repository.

Emails and quick fix for the Nxtlinq AI agent SDK file. Recording notes from the past couple of days (11/17/25 to 11/18/25).

Working on new content for the adilas lite and fracture plan. Shannon and I were in the section dealing with desktop first, responsive design, and mobile ready options. We had a great little session. Here is what we came up with:

/////

We are focused on a desktop first design that is also responsive for tablets and phones. This means that the whole system will be built to work on desktop and laptop computers first. Mobile first design is great for simple apps, but we have built a complex app that needs a desktop first design. Most of our clients and users are physically at a computer while working on adilas. There is no way to get huge reports or data capture forms into a super small mobile view without losing functionality. Focusing on desktop first design allows us to create a full featured experience for our users.

Even though the focus will be on desktop first, we will be building out the entire fracture project with a responsive design. Responsive design means that the system will adapt to different screen sizes and devices. This allows us to create a seamless experience for users, regardless of the device they are using.

Full mobile ready design, and functionality, will be used in customer facing portals, ecommerce, and other specific use cases. We will also create certain admin and user interfaces that are more mobile friendly. Most of these smaller mobile friendly apps will help with specific tasks and functions. That will keep the mobile experience focused on the task at hand while still being able to fall back on the full desktop experience when needed.

One of the goals of fracture is to empower the users to customize their own user experience. That means that, based on the user and their device, they can toggle on/off any buttons, features, report columns, etc. That allows a desktop user to customize their workspace, while a more mobile type user could simplify their interface. This flexibility is key to ensuring that all users can work in a way that is most comfortable and efficient for them. Our users vary greatly, some like touch screen, others use their phones, while others are mouse and keyboard people with multiple monitors. Our goal is to create a dynamic application where each person feels in control of their own experience.

Our other hope is that outside users will catch the vision of the API and build out specialty mobile apps that connect to the adilas backend via the API. This would allow for more specialized mobile experiences that are tailored to specific industries or use cases. This could be simple native mobile apps, SPA's (single page apps), custom interfaces, or other types of mobile friendly apps. More information is available in the API section above (the real pages doesn't have a link here, but it refers to the fracture plan and the API section of that plan) or from the adilas marketplace.

Getting back into the partial PO project. Here is a small list of things that still need to be done for that project.

- Open up the external_alternate_id field for all of the 12 main player groups. They, the database tables, already have that field, it is just hidden and not being used right now.

- In-store credits (customers and invoices) - new special account option

- Vendor specific or category specific PO line searches - add lines in bulk - somewhat of the reverse shopping cart for PO's - the normal shopping cart is for invoices and quotes.

- Full visibility - track total request quantities, total live quantities, and total still on backorder quantities.

After doing some review, I spent some time looking at what it might take to help add bulk po line items. Created a new branch to work on some of the new functionality. Started working on a new page for bulk adding PO line items. Took the original code from the parts homepage and then worked on tweaking it out a bit. The page will allow for filtering parts and items by vendor, by category, by item, by description, by location, etc. That should really help speed things up.

Emails and paying bills. On the phone with Bryan going over some ideas. Talking about custom development, running specials on development (prices), helping with training manuals, and having a custom code budget per customer, if needed to help make the sale.