Before industry software can solve an industry problem, it needs a dependable place for people, records, documents, and work in progress. Our platform brings those recurring capabilities together, so each product can concentrate on the work that makes its industry different.
This is a shared foundation in development, exercised through a reference application. It already contains the capabilities described here. A product still has to assemble them into useful workflows, add its own domain behavior, and prove the result with the people who will use it. Construction is where we are beginning that product work.
People belong to companies, with different responsibilities
A person has an account. Their work happens within a company, where they have a membership and a set of permissions. Keeping those concepts separate lets a person belong to more than one company while the application keeps the active company context explicit.
The platform has company-switching machinery that rebuilds permissions and resets the relevant collections when that context changes. Permissions are assembled from roles, additional grants, and the modules available to the company. Products can distribute responsibility without making everyone an administrator.
The checks extend below the interface. Server authorization adds company scope to permission rules, database operations receive company and actor context, and synchronized reads have server-controlled boundaries. Hiding an action in a menu is only one part of presenting access correctly; the request itself also needs to be checked.
Company security settings can require a second factor at sign-in. The platform distinguishes the need to enroll, complete a challenge, or continue with an already satisfied session. These capabilities give a product a starting point for company access policy, while security still requires careful integration and ongoing review.
A document is more than an uploaded file
Operational work produces revisions. A file arrives, somebody corrects it, and another person needs to know which version they are using. The documents module keeps a document record with version history, rather than treating every revision as an unrelated upload. It also has folders and controlled attachment mechanisms for connecting documents to other records.
That connection is useful because files usually belong beside a task or decision. Creating or removing that connection requires update access to both the document and the record it is attached to. Each industry product must still define the records and relationships that matter to it; a shared attachment mechanism does not by itself create a construction workflow.
New uploads pass through scanning and processing states. Processing includes supported previews, text extraction, OCR where appropriate, and preparation for search. The pipeline represents partial results and failures explicitly, including formats that cannot be processed fully. People need a truthful status when a file is available but some of its contents are not yet searchable.
Search for what a document contains
Remembering a filename is a poor substitute for knowing what you need. The document search implementation searches names and extracted passages, with permission filtering applied before results are limited. Ranking, snippets, and a typo fallback help turn a query into something a person can inspect.
Word search and semantic indexing are separate stages. Extracted words can become searchable while the later embedding work waits or fails. That separation makes the ordinary search capability useful without requiring every intelligence-related step to finish first.
For a person looking for a passage in a report, the benefit is direct: search can return material based on its contents, with enough surrounding text to decide whether it is relevant. The quality of that result still depends on the document, successful extraction, and the permissions of the person asking.
Intelligence with something to check
The document question-and-answer flow builds on that searchable material. It can work within a chosen document or folder scope, retrieve relevant passages, and record references to the supporting material. Citation details can identify a document version and locations such as a page or sheet.
This gives an answer a path back to its evidence. A person can inspect the source rather than accept a detached paragraph as the end of the task. The retrieval tools remain within the caller’s scope, and document intelligence is subject to the company’s feature settings.
Citations make review possible; they do not make an answer automatically correct. A product still needs to choose the questions it supports, communicate uncertainty, and decide which actions require a person’s approval. We want intelligence to have a job whose result can be checked.
Construction estimating and takeoffs are future product work in our presales direction. Document processing and retrieval provide useful foundations, but they do not establish that an estimate is complete or a quantity is right. Those tasks need domain-specific development, evaluation, and people who know how to review the result.
Longer work should have a life beyond the request
Some operations take longer than a person should wait inside a single web request. Extracting documents and preparing previews are examples of longer processing tasks that can run as durable jobs with a status and an outcome. The platform records job intent and runs work through staged pipelines.
Those pipelines separate computation from the transaction that saves a result. Committed steps are designed to be replay-safe, and redelivered events are handled without blindly starting the same run again. Retry behavior is controlled: some failures end a run, while eligible failures can be attempted again.
The business benefit is continuity. A longer task can be tracked as work in progress, with an eventual result or an explicit failure, instead of depending entirely on the original screen remaining open. The product must make that status understandable and provide the right next action.
Keep people informed without making them refresh
Company- and person-scoped event streams let an application communicate changes as they happen. The implementation includes authorization rechecks and reconnect handling, including replay or resynchronization. A product can use that machinery to keep the right view current after work completes.
Notifications provide another layer: information intended for a person can become an in-app notification, with controlled email channels where configured. Multi-recipient delivery has deduplication support, so notifying a group is a deliberate operation rather than an unstructured loop of messages.
These foundations give product teams ways to answer two different questions: has the information on this screen changed, and is there something this person needs to know? Choosing useful events and avoiding unnecessary interruptions remains part of the product design.
Be precise about work saved on a device
The platform includes support for selected offline changes, with company-specific queues that can send work when a connection returns. The documents interface also includes local file and photo capture with explicit saving, saved, and failed states.
A file saved on a device has not necessarily been uploaded, scanned, or processed on the server. Those stages should stay distinct in the interface. Some actions, including document template application and bulk operations, require the server. We are building reusable support for interruptions; each finished workflow needs a clear account of what it can do without a connection.
Company access and intelligence usage are separate concerns
Our commercial direction is a company base fee with no charge for each additional user, alongside credits for hosting and intelligence usage. That makes participation a different decision from the amount of variable processing a company chooses to consume.
The platform has company billing machinery and metering for intelligence work. Configurable company and member limits can reserve estimated AI spend before work runs. Supported pipeline steps can pause at a configured company AI spending limit and resume when that limit changes or a new month begins. The effect depends on the limits and enforcement mode selected for that deployment.
That distinction should be visible to a customer. Inviting another person to work with the team should not be confused with authorizing unlimited inference. The planned model and its allowances are described in our software economics field note; the platform is the machinery through which that direction can be implemented.
| Platform foundation | Practical benefit | Still specific to the product |
|---|---|---|
| Accounts and permissions | A common model for people, companies, and responsibilities | Which roles can perform each industry action |
| Documents and search | Versioned records and ways to find their contents | Where documents belong in the workflow |
| Pipelines and metering | Tracked background work with configurable usage controls | Which tasks run and how their results are reviewed |
| Live updates and notifications | Ways to keep views and people informed | Which changes are useful enough to surface |
The shared work makes room for the specific work
The platform carries recurring engineering forward. Shared packages give products a common foundation, while product-owned domain modules can develop around their own needs. A change to a shared capability is not an instruction to make every industry operate in the same way.
For construction, inventory management and time tracking are the first focus. Presales workflows, including estimating and takeoffs, come next. The ambition is a connected end-to-end system, built in useful stages. The platform contributes the common services; industry knowledge tells us what the product on top should actually do.