Using these docs
What this site is
Section titled “What this site is”Documentation for KI, the software the business runs on, written for the people who run it. The letters stand for Kinetic Intelligence. Everyone says KI, and the full name turns up in contracts and on a few screens meaning the same thing.
This site explains how a job moves from first contact to final billing, which interface owns which part of that, and what the vocabulary means.
It assumes you know construction. It does not assume you know this software, which is the reason it exists.
One system, several interfaces
Section titled “One system, several interfaces”Most confusion here comes from the same root: KI is not one screen, and which interface you open depends on what you are doing.
The Admin Portal is where most employees work. Legacy KI is the older admin portal, and the one the new portal is being ported from. The Client Portal is what the client sees, the Vendor Portal carries purchase orders out to vendors and subcontractors, and the Field App is what site teams use on an iPad.
Legacy KI matters for one reason: it points at the same database as every other interface your company uses, so work done there is live data rather than an archive. For parts of your job it is the system of record right now.
Where a page can tell you which interface to open, it does. Where the answer is genuinely “it depends,” it says that too.
Two entities, and the switch in the header
Section titled “Two entities, and the switch in the header”Story and Bristlecone Construction are sibling companies, and each runs its own copy of KI — its own database, its own configuration, its own set of interfaces switched on. They share the software and nothing else, so work done in one does not appear in the other, and a feature one has is not evidence the other has it.
Pick yours with the Story / Bristlecone switch in the header. Your choice is remembered as you move around.
The capability pages exist twice, once per company, and the switch decides which you get. An area that does not apply to you is not in your navigation — there is no Design section on the Bristlecone side, for instance, because Bristlecone does not run a design phase. Switching mid-page takes you to your version of it.
Story is the default, because most of these pages were written against Story’s instance and it has the larger readership. The feature matrix shows both at once, deliberately.
The two are genuinely different. Bristlecone works in Legacy KI, commits subcontractors through Commitments rather than Purchase Orders, prices changes as Change Estimates, runs no design phase, and does its field work in Autodesk. None of that is true of Story.
Where to go
Section titled “Where to go”| If you want to know | Go to |
|---|---|
| What KI is, and how the two companies relate | The software |
| What Story and Bristlecone each have switched on | Feature matrix |
| What the objects are and what arithmetic the system enforces | Part 2 — Objects and rules |
| How a job is structured — intake, scope, phases, contracts | Part 3 — How a project runs |
| Which screen does what | Part 4 — The interfaces |
| One business area in detail | The By area pages in the sidebar |
| What ships each week, and what a version number means | Releases |
| A quick answer to a common question | FAQ |
| What a particular word means | Glossary |
Two shapes of page
Section titled “Two shapes of page”The KI system guide describes KI the way it is built: what the objects are, what rules hold between them, which interface owns which part, and a project walked end to end from intake to completion. Start at Part 1 if you are new, and read it in order.
The By area pages describe the same system by the business area each part serves — estimating, contracts, cost control, scheduling, and the rest. They are the faster route when you already know what you are trying to do. Each follows the same shape: what the area does, how it works, what the client sees of it, and which interface the work actually happens in.
They are two views of one system rather than two systems. Where they disagree, the guide is the source of truth and the area page is the one to fix.
What these pages promise
Section titled “What these pages promise”They describe what ships, not what is planned. If a capability is on the roadmap, it is not written up here as though you could use it today.
They say where the edges are. If something you would reasonably expect to find has no screen in the Admin Portal, the page says so and points you at where the work gets done instead. That is the most useful sentence on some of these pages.
They do not generalise one entity to the other. A statement is about the entity in the header switch. Where a capability exists in only one, the page says which.
Something wrong?
Section titled “Something wrong?”If a page contradicts what you see on your screen, the software is right and the page is wrong — tell us. Highlight the passage that is wrong and leave a comment; it goes to the team as a suggested edit.
Pages describing how a process should run are a different matter. Where those diverge from what your team actually does, that is worth a conversation rather than an edit.