Part 1 — Orientation

1. What KI is

KI is our ERP — enterprise resource planning, the single system a business runs its operations and its money on, so that a project, its costs and its billing are all the same record rather than three that have to be kept in step. And it is one product that two companies run separately. Story and Bristlecone Construction are each a customer of it in their own right, with their own database, their own configuration, their own QuickBooks company, and their own set of interfaces switched on. What they share is the software. The data is not shared: nothing entered in one appears in the other, and no screen anywhere shows both.

Everything on these pages describes the instance selected in the header switch.

Within one instance, KI is not a single application but several user interfaces over one database — the same definition of what a project is, how cost is classified, how money is committed and spent, and how work gets billed, whichever screen you open. A change made in one place is immediately visible everywhere it matters. Nothing is re-entered, and nothing has to be reconciled between interfaces. That is a claim about your own company’s KI, and only about it.

Which interface you use depends on who you are and what you are doing.

Interface	Who uses it	What they do there
Client Portal	Clients	See their project, review and approve packages, sign contracts, pay invoices, log issues
Admin Portal	Most employees	Set up projects, move them through their phases, manage them financially
Vendor Portal	Vendors and subcontractors	Receive purchase orders and interact with us
Field App	Field teams	Project updates with photos, issues, the current plan set, and time entry
Legacy KI	Accounting, estimating, admin	The older interface we are migrating away from — several modules still run here

One database per instance is the architectural fact everything else depends on. Legacy KI is not a separate copy or an archive: it points at the same database as current KI, so work done in those modules is live data. See section 18.

CLIENT PORTAL     ADMIN PORTAL      VENDOR PORTAL     FIELD APP        LEGACY KI
review, approve,  set up and run    purchase orders,  updates, photos, pricing, admin
sign, pay, log    projects and      confirmations     updates, plans   setup, accounting
issues            financials
     │                 │                  │                │                │
     └─────────────────┴──────────────────┴────────────────┴────────────────┘
                                     ▼
                        STORY'S OWN KI DATABASE
          Story ▸ Divisions (Dallas · Denver · Scottsdale) ▸ Projects

2. The company, Divisions, and Projects

Above the interfaces sits the company structure everything in KI hangs from.

Story is the overarching company. Inside Story are Divisions — Dallas, Denver and Scottsdale today, with more to be added, each split into Design, Construction and Overhead. That is why the Division picker is longer than the list of offices. Every project belongs to exactly one Division.

Division is not just a label. It is how projects are grouped, searched, and reported on, and it is the level financial reporting rolls up to: WIP — the work-in-progress report — is run by Division and contract grouping so that it ties to the P&L (section 19).

The company and its Divisions are set up in the Admin section of Legacy KI, and each Division carries the QuickBooks Class its figures are sent across in: every cost, every dollar of revenue and every payroll journal lands in the Class mapped to the project’s Division. Get the Division wrong and the figures land in the wrong Class, which is why the mapping matters more than the label suggests.

The mapping is not one to one. Design, Construction and Overhead in a city all point at that city’s single Class, so QuickBooks reports one level coarser than KI does: by office, not by discipline. Splitting design from construction is a question for KI, not for the general ledger.

Story
 └── Division  (Dallas · Denver · Scottsdale · …)
      └── Project Record
           ├── Design Contract
           └── Construction Contract

2.1 One product, two companies

Story and Bristlecone Construction are sibling companies, not one company with a filter on top. Each runs its own instance of KI, with its own database, its own configuration, its own set of features in use, and its own QuickBooks company. Work done in one does not appear in the other.

The two instances began as the same product and have not stayed identical. Each has been shaped around how that company actually builds — which contracts a job carries, who approves what, which screens anybody opens on a Tuesday — and the Admin Portal port is advancing on Story’s instance and not yet on Bristlecone’s. So the difference between them is not only which switches are on.

That has a consequence worth stating plainly: a statement about how KI behaves is a statement about one instance. Not every capability is used in both. Where a feature exists in one and not the other, these pages say so rather than describing it as part of the workflow.

The clearest example is the Change Estimate. Bristlecone prices a change as a Change Estimate before it becomes a Change Order; Story does not — in Story’s instance a Change Order is created directly, with no Change Estimate predecessor. The feature matrix lists the rest area by area.

When writing code, do not assume that a feature, a field, or a table present in one instance exists in the other. Instance-specific behaviour belongs in configuration rather than in a fork of the model, but the two databases have drifted far enough that “it works in Story” is not evidence about Bristlecone. Check the instance you are targeting.

3. Story Design Studio

Story Design Studio is a marketing tool on our public website, not part of KI. A prospective client uploads photos of a room, describes what they want, and gets AI-generated design images back — a way to see what a space could become before talking to anyone.

It does not touch projects, cost codes, or money, and it creates nothing in KI. A lead that arrives through it enters the same way as any other, through the CRM — our customer relationship management system (section 6.1).

It sits ahead of everything in this guide, at the widest part of the funnel. We expect to expand it later; when we do, it will be documented here.