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
Legacy KI	Everyone	The admin portal for this instance — projects, estimating, commitments, cost control, pay applications, accounting
Autodesk	Field teams	Field management, submittals and daily logs. Not part of KI

Nothing has moved to the new Admin Portal yet, and the Client Portal and Vendor Portal are not set up on this instance. Legacy KI is not an old name and not an archive — it is the interface you work in, and it is the one the new Admin Portal is being ported from, module by module. See section 18.

LEGACY KI                                        AUTODESK
projects, estimating, commitments,               field management,
cost control, pay applications, accounting       submittals, daily logs
     │                                                 │
     │                                            (outside KI)
     ▼
BRISTLECONE'S OWN KI DATABASE
Bristlecone Construction ▸ Divisions ▸ Projects

The rest of this guide is written against Story’s instance except where a section says otherwise, because that is where the port is happening and where the behaviour has been documented. Where a screen you open disagrees with a page here, your screen is right — say so through the comment link and it reaches the team as a suggested edit.

2. The company, Divisions, and Projects

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

Bristlecone Construction is the company, and inside it are Divisions — here the lines of business it runs rather than the offices it runs them from. Two carry work today: Bristlecone GC and Bristlecone Concrete, which self-performs. 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.

Bristlecone Construction
 └── Division  (Bristlecone GC · Bristlecone Concrete)
      └── Project Record
           └── 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.