SharePoint Permissions for AI Search: A Civil Engineering Guide
AI DOCUMENT SEARCH • SHAREPOINT PERMISSIONS • May 2026
SalemWise builds permission-aware AI document search for civil engineering firms: access is trimmed by role before search, so restricted projects never reach the answer, and mapping to the firm's existing permissions is set up during deployment. It runs on your hardware (a local NVIDIA GPU on your network) or ours, and charges flat, not per seat. From $21,000, $1,500–$2,000/mo.
Here is a typical scenario. At 4:47 on a Friday, the managing principal of a 40-engineer civil firm gets a call she does not want. A senior PE has just received a Microsoft 365 Copilot answer that cites a sealed expert-witness report from a 2019 litigation the PE was conflict-walled off from. Copilot did exactly what Microsoft built it to do: it returned what Microsoft Graph could see. The problem is that a partner had moved the folder six weeks earlier, nobody re-ran permission propagation, and the index was serving a stale access-control list. A conflicted partner now holds a document he was obligated not to have, and the firm's professional-liability carrier has to be told.
This is not a Copilot bug, and it is not rare. It is the predictable result of treating document-level permissions as a thing you set once when files are indexed rather than a thing you check on every question. For the principal who carries partner-level liability on stamped work, a permission leak is not an IT inconvenience; it is a malpractice-shaped exposure with a dollar figure attached. For the engineer who actually has to trust the tool, it is the reason a generic AI search never gets used on the matters that count. This article covers how SharePoint permissions break in a 30-year engineering archive, what a single leak now costs in a hardened 2026 insurance market, and what an AI search has to do so it never happens. Pricing is published below.
What does an AI search tool actually see when you point it at SharePoint?
It sees what Microsoft Graph indexes, and that is not your archive. Microsoft Graph covers SharePoint Online, OneDrive, Exchange, and Teams. It does not index ProjectWise vaults, NTFS shares on the legacy file server, or the 1996 plan set scanned at 200 dpi sitting on a standalone drive. In the typical 30-to-250-person civil firm, the share of project content that lives in surfaces Graph can see is well under half. Everything else needs a separate ingestion path, and every separate path needs its own permission-propagation path. The Copilot connector library, which we covered in the Microsoft Copilot review, has more than 100 entries and no ProjectWise connector. The permission version of that same gap is harder, because a tool either propagates the correct ACL or it leaks the wrong document. There is no partial credit.
Three permission failures account for most of the risk, and each maps to a specific event that happens at a partnership firm on an ordinary week.
1. Inheritance the index never re-reads
SharePoint permissions inherit down a hierarchy: site to library to folder to file, unless someone breaks inheritance at a level. Microsoft's preview SharePoint indexer for Azure AI Search captures those access-control lists, but per Microsoft Learn the capture happens once, at first ingestion: "During preview, ACL ingestion applies to initial indexing only. ACLs are captured on the first ingestion of each file." When a partner re-organizes a project folder, the captured ACL and the live ACL diverge, and nothing re-reads the source until something forces it to.
2. Group types the indexer cannot resolve
The preview indexer resolves Entra users and groups. It does not resolve native SharePoint groups. Per Microsoft Learn, unsupported permission types include "SharePoint groups that can't be resolved to Microsoft Entra groups (such as Owners, Members, Visitors groups)." Firms that built their project access on the default Owners/Members/Visitors model, which is most of them, have a permission structure the preview indexer was never designed to honor.
3. The library that silently stops accepting permissions
SharePoint caps unique permissions per library. Per Microsoft's service description, "the supported limit of unique permissions for items in a list or library is 50,000. However, the recommended general limit is 5,000." A major project with per-discipline subgroups and per-sheet carve-outs can blow past 5,000 in a single lifecycle, and query performance degrades long before the hard cap. What actually breaks at the cap is covered later in this article.
The three queries below are the ones that expose permission failures rather than retrieval failures. That distinction is the whole point of this article.
Query 1: "Pull the 2019 expert-witness report on the [litigated project]." The report was sealed and walled off from any PE with a conflict on the matter. If the index captured the ACL before the conflict wall was applied, or if the wall lives in a SharePoint group the indexer cannot resolve, the report comes back to a conflicted engineer who should never see it. That is a disclosable event to the affected client, not a search-quality miss.
Query 2: "Find the geotech report for [acquired-firm project], restricted to the [office] partners." After an acquisition, two firms' tenants and security groups have to merge, and the cleanup lags the close by months. During that window a restricted report is permitted to the wrong group, and an engineer at the acquiring office retrieves a document the acquired firm's partners had deliberately fenced. The permission model was correct in the source the day before the migration and wrong the day after.
Query 3: "Show me the draft RFP response for the [competing pursuit]." BD walled this draft off from a principal who happens to sit as a referee on the client's selection panel. An AI assistant that returns it has just handed the principal a document whose contents he is obligated not to have. None of the three queries is a failure to find the right file. Each is a failure to respect who is allowed to see it.
Why do generic AI search tools mishandle engineering ACLs?
Because most of them evaluate permissions against a snapshot taken at ingestion, and an engineering archive's permissions change constantly: a junior joins a project team, a partner moves a folder, an acquisition closes, a litigation hold lands. Two named tools handle this honestly and differently, and neither is wrong for its own buyer.
Microsoft 365 Copilot honors Graph access controls natively at query time, which is genuinely strong: per Microsoft Learn, "Copilot can only summarize or reference content that the user is authorized to access." The limitation for civil engineering is that this guarantee only covers content Graph indexes, and Graph does not reach the network shares and ProjectWise vaults where most of the archive lives. Glean enforces permissions in real time across its connectors and markets that "Glean enforces real-time indexing and respects existing permissions, so users only access what they're allowed to see." The limitation for a partnership firm is the per-seat enterprise price floor, which is hard to justify when eight people, not a hundred, actually run searches. SalemWise differs on three things: access is trimmed by role before search, so restricted projects never reach the answer, with the mapping to the firm's existing permissions across SharePoint, network drives, and ProjectWise set up during deployment; the permission audit we run during setup checks for the SharePoint permission-scope cliff that the others surface only as degraded performance; and it processes the archive with an open-weight model on your hardware or ours, so a firm's stamped documents are never routed to a public AI API.
| M365 COPILOT | GLEAN | SALEMWISE | |
|---|---|---|---|
| Permission evaluation | Query-time, against Microsoft Graph ↗ Microsoft Learn | Real-time, mirrored across connectors ↗ glean.com | Trimmed by role before search; mapped to your permissions during deployment ↗ salemwise.com |
| Surfaces covered | SharePoint Online, OneDrive, Exchange, Teams | 100+ SaaS connectors | SharePoint, network drives, ProjectWise |
| Network drive ACLs | Not native | Via connector if exposed | NTFS ACLs mapped read-only during setup |
| SharePoint groups | Native | Supported | Mapped to your Entra groups during setup |
| 5,000-permission cliff | Surfaces as degraded performance | Surfaces as degraded performance | Checked in the permission audit during setup |
| Where content is processed | Semantic index inside your M365 tenant | Central index, Glean-hosted cloud | Your hardware (a local NVIDIA GPU on your network) or ours |
| AI inference | Microsoft-operated models in the service boundary | Glean-hosted models over the copied index | Open-weight model on your hardware or ours; never a public AI API |
| Pricing model | $30/user/mo Enterprise; $21 Business (as of September 2026) | ~$60K enterprise floor | Flat, from $21K + $1,500–$2,000/mo |
| Best for | Firms whose archive is fully inside M365 | Tech-company horizontal search at scale | Civil firms with hybrid SharePoint + drives + ProjectWise |
What does permission-safe AI search have to do for a civil firm?
Five things have to be true before a firm should trust AI search on stamped work. A platform that misses any of them is not a real option for an engineering archive, regardless of how good the demo looks.
-
01Evaluate ACLs at query time, not ingest time Permissions checked against the live Entra ID store on every retrieval, so a folder a partner moved an hour ago is reflected now. An index-time snapshot is acceptable for a static public corpus; it is not acceptable for active litigation, M&A diligence, or conflict-walled matters where freshness is the whole control.
-
02Resolve every group type, including broken inheritance SharePoint Owners/Members/Visitors groups, Entra security groups, and per-folder broken-inheritance carve-outs all map cleanly into the access decision. A folder that broke inheritance to lock a sealed report has to be honored, not flattened back to the parent's permissions.
-
03Reach the surfaces Graph cannot see NTFS ACLs on network shares and security-set membership in ProjectWise carry their own permission models. The system reads them over a read-only path and maps them into the same identity decision as SharePoint, so one query honors three permission stores at once.
-
04Detect the SharePoint permission-scope cliff Per Microsoft, a library at the unique-permission limit refuses further inheritance breaks with the error "You cannot break inheritance for this item because there are too many items with unique permissions in this list." The audit flags libraries approaching 5,000 scopes so the firm reorganizes before the failure, not after.
-
05Maintain a do-not-index allowlist Litigation holds, sealed expert-witness work, and conflict-walled matters get an explicit exclusion that no permission change can override. A document under hold should not enter the index at all, regardless of who later gains folder access.
How does query-time ACL enforcement actually work under the hood?
The mechanism is a different problem shape than indexing text. Indexing answers "what does this document say." Permission enforcement answers "may this specific person, right now, see it." The first can be cached; the second cannot, because the answer changes the moment a folder moves. The pipeline below is a reference architecture for permission-safe retrieval. The cold-start problem, getting permissions right on day one, is solvable with care. The steady-state problem, staying correct after the archive changes, is where most deployments break, and it is the reason a permission-safe design checks the live identity store rather than trusting a snapshot. Corpus today trims access by role before search runs, and the live demo shows it. Mapping those roles to your Entra groups, NTFS shares and ProjectWise security, and deciding how often permissions resync, is setup work we do with your IT lead during deployment.
What we build with your IT lead during setup (reference design):
-
01Identity resolves from the Entra ID token A query carries the engineer's Microsoft Entra principal. The retrieval layer expands that principal into its full group membership at request time, including nested groups, so a person added to a project team this morning is evaluated with this morning's membership, not last night's crawl.
-
02Permission metadata is stored alongside each chunk At ingestion, each document's resolved ACL, the SharePoint inheritance chain, the NTFS ACL, or the ProjectWise security set, is stored as filter metadata on every retrievable chunk. This is the snapshot. It is necessary for performance but never trusted as the final word.
-
03The live store re-validates before any chunk is returned Candidate chunks from the semantic and keyword search are filtered against the stored ACL, then the surviving set is re-checked against the live Entra membership for sensitive scopes. If the live store and the snapshot disagree, the live store wins and the chunk is dropped. Microsoft's own preview indexer instead serves the snapshot until a resync runs, which is the stale-ACL gap this step would close.
-
04Failures fail closed If the identity store is unreachable, the query returns no results rather than an unfiltered set. A permission system that fails open is worse than no permission system, because it leaks silently. Fail-closed is the only acceptable default for stamped engineering work.
-
05Continuous delta-sync keeps the snapshot honest A scheduled delta-sync re-reads changed ACLs across SharePoint, network drives, and ProjectWise, so the stored snapshot the fast path relies on never drifts far from the source. Moved folders, new group members, and revoked access propagate on the sync cadence rather than waiting for a full re-crawl.
-
06Every answer carries a page-level, permission-checked citation The returned answer names the document, the page, and the section, and that source passed the same ACL check as the chunk it grounds. The PE who stamps the work gets the traceback for QA and litigation defense; the principal gets an audit trail the firm's professional-liability carrier can read.
There is a second half to this trust story, and it matters as much to the principal as the ACL layer. The permission layer decides which human may see a document. The inference architecture decides where the document goes to be read. In a SalemWise deployment, the archive is loaded onto a local NVIDIA GPU on the firm's network or into a tenant-isolated environment SalemWise hosts, and the model that generates the answer is an open-weight model running inside that environment. A query and the documents it retrieves are processed only by that model. They are never sent to OpenAI, Anthropic, Google, or any third-party AI API, and they never become training data for anyone's model. During setup we build a do-not-index list for the most sensitive material, sealed expert-witness work and conflict-walled matters, so it is excluded from ingestion and never reaches the environment at all. For a firm whose archive holds documents like these, that combination, no public AI API plus a hard ingestion exclusion for the untouchable material, is not a feature line; it is the difference between an architecture a professional-liability carrier can sign off on and one it cannot.
For the global mining consultancy version of this problem, the permission boundary is not a folder ACL but identity federation across SSO realms. A firm with offices on several continents often runs separate Entra tenants per region for data-residency and acquisition reasons, with cross-tenant access settings governing guest and contractor access. The retrieval layer has to know which home tenant issued a token and apply that tenant's ACL space, so a document permitted to home-tenant employees is still blocked to a cross-tenant guest. That is precisely the case Microsoft's single-tenant preview indexer was not built for, and it is a separate engineering conversation from the folder-ACL story above.
What would a civil engineering deployment look like (illustrative)?
Illustrative scenario based on engineering firms we have scoped. It is not a live customer deployment.
Picture a partnership-structured civil firm of about 40 engineers. Water and wastewater is half the practice, transportation a third, structural and site civil the rest. The archive is several terabytes on SharePoint Online plus a shared network drive, with legacy scanned drawings on a separate file server. M365 E5 firmwide; Copilot Enterprise turned on for the partners and senior PEs. Identity runs through Entra ID.
In this scenario, the trigger is the Friday-afternoon call in the opening of this article. A folder holding a sealed 2019 expert-witness report had been moved during a routine project-archive cleanup, the conflict wall lived in a SharePoint Members group, and the firm's existing index served the pre-move ACL. A conflicted senior PE received the report in a Copilot answer. Nothing in the source was technically misconfigured the day the wall went up; the index simply never re-read it. The managing principal called her professional-liability broker, and the broker asked the one question the firm could not answer: which people had been able to retrieve that document, and on which dates.
In this scenario, Corpus would run on a local NVIDIA GPU on the firm's network or in a tenant-isolated environment SalemWise hosts, reading the SharePoint, network-drive, and ProjectWise sources over a read-only connection we build during deployment, with answers in the browser or in Microsoft Teams. Access would be trimmed by role before search, mapped to the firm's existing permissions during deployment, so the sealed 2019 report and the other conflict-walled documents would never reach a conflicted principal's answer, and no query or document would be routed to a public AI API. The broker's question, who could see a document, would be answered from that role mapping rather than a forensic reconstruction. And because the citations are page-level and the answers are grounded in the actual reports, the senior PEs would have a reason to use it on the matters that count, which is the test a generic tool had failed. In this scenario the firm would keep Copilot for email and meetings, with archive retrieval running alongside it.
What does a permission leak actually cost a 40-engineer firm?
The first four SalemWise articles framed return on investment as hours saved per engineer per week. For the economic buyer weighing a security spend against partner equity, that is the wrong number. The number that matters is the cost of a single permission-leak incident, and in 2026 that cost moved in two directions at once.
AI used in stamped engineering work just acquired its own insurance exclusion. In January 2026 ISO introduced Form CG 40 47, which per construction-law analysis "presents language for claims arising from generative AI outputs" under commercial general liability policies. At the same time the professional-liability market hardened: the Ames & Gough 2026 survey of 15 leading A/E insurers found 73% planning rate increases, and per the survey 80% now view AI adoption by design firms as a potential market disruptor, with civil engineering ranked the second-highest-severity discipline at 73%. A firm that ships an AI-generated answer built on a document that was sealed for conflict reasons is exposed twice: under E&O for the consequences of the disclosure, and under a freshly excluded CGL gap for the AI provenance of the answer.
The math does not need to be precise to be defensible. It needs to be honest and sourced.
| Option | Year 1 cost | Permission-leak exposure |
|---|---|---|
| Generic AI search, index-time ACL snapshot | License cost only | One stale-ACL incident per 5-year window carries deductible + next-renewal rate multiplier + partner-hour breach response, against a hardening market where 73% of insurers are raising rates |
| SalemWise, access trimmed by role before search | ~$39,000–$45,000 ($21K+ setup plus $1,500–$2,000/mo ongoing) | Same incident probability reduced because access is trimmed by role before search, so restricted projects never reach the answer |
| Do nothing; keep archive un-searchable | $0 direct | No leak risk from AI, but the retrieval problem stays unsolved and senior-PE archive time stays leaked |
The recommended row is the second. For the principal, the argument is not "it saves hours," it is "it closes a partner-level liability the firm's own CGL now excludes." A single disclosable conflict-wall breach, between the E&O consequences and the partner hours burned on the breach response, exceeds a year of the contract before the rate-hike multiplier is even counted. And the contract is flat: it runs on your hardware (a local NVIDIA GPU on your network) or ours, and it is priced as one deployment rather than per seat, so a firm where eight people run searches is not billed like a hundred. The per-seat math that makes enterprise search painful for a partnership does not apply.
When is SalemWise the wrong tool for the permission problem?
Several cases disqualify a firm, and an honest IT evaluation should rule them out fast.
Firms whose archive is entirely inside M365
A firm founded recently, on SharePoint Online from day one, with no network drives, no ProjectWise, and clean Entra-group hygiene, already has query-time permission enforcement through Copilot. The cross-surface permission layer SalemWise adds solves a problem that firm does not have.
Firms that have not cleaned up SharePoint oversharing first
If a tenant is riddled with "Everyone except external users" grants, no AI permission layer fixes that, because the source permission is wrong, not the propagation. Microsoft's own guidance is to remediate oversharing before enabling Copilot. The same applies here: clean the source ACLs first, then add the retrieval layer.
Firms with fewer than ~20 engineers and no legacy archive
Where the managing principal still does most of the searching personally and there are no conflict walls in play, the permission-leak exposure that justifies the spend is too small to carry the setup cost.
CMMC Level 3 CUI subcontractors with data-residency clauses
When SalemWise hosts the index and the model on its own infrastructure, that is the right trade for most commercial firms and the wrong one for a subcontractor whose contract requires controlled unclassified information to stay inside a government-authorized boundary. Corpus can instead run on a local NVIDIA GPU on your network, but CUI obligations cover more than where the server sits, so if your work carries them, treat this as a first-call question, not a configuration option, and we will say plainly whether we fit. As with the Deltek Dela review's treatment of federal scope, this is flagged, not glossed.
How does the deployment and security review actually run?
Yermek Ibray is an ex-Meta and ex-Google software engineer who builds Corpus, page-cited AI search for civil and mining engineering firms. Corpus runs on your hardware or ours: the index and an open-weight model run on a local NVIDIA GPU on the firm's network, or SalemWise hosts both in a tenant-isolated environment on infrastructure we run and secure, so the firm carries no GPU cost. Either way, queries and documents are processed only by that model and never sent to a public AI API. SalemWise does not have a SOC 2 report. More at salemwise.com/about.
-
01Free call, then scoping (weeks 1-2) A free 30-minute conversation about where your archive lives, how permissions are set up and which matters are walled off. Mapping the archive surfaces, the identity topology in Entra ID and the conflict-wall and litigation-hold requirements is paid scoping work. Its output is a threat model and a deployment-and-security reference architecture the firm can put in front of its partners and its professional-liability carrier.
-
02Permission audit and read-only access (weeks 2-3) A read-only sweep classifies the SharePoint libraries, flags those approaching the 5,000-unique-permission cliff, surfaces "Everyone except external users" overshares, and inventories the broken-inheritance carve-outs and do-not-index candidates. This runs before any content is indexed.
-
03Deployment and indexing (weeks 3-6) The retrieval stack and the open-weight model stand up on a local NVIDIA GPU on the firm's network or in a SalemWise-hosted, tenant-isolated environment. The archive is ingested over a read-only connection we build during setup to the firm's SharePoint, network drives, and ProjectWise. Access is mapped to the firm's existing permissions. Inference stays inside that environment; no query or document is sent to a third-party AI API, and a do-not-index list we build during setup is applied before anything is indexed.
-
04First discipline live (weeks 6-7) A single discipline's recent project archive is indexed with access trimmed by role before search, and the conflict-wall and do-not-index rules are validated against deliberately constructed permission-leak test queries before any wider rollout.
-
05Firm-wide rollout (week 8) Indexing extends across disciplines, delivered through a secure web interface inside the firm's network over VPN, or Microsoft Teams where the firm prefers it, with permission resync on the schedule agreed during setup and an audit trail of retrievals by identity, source, page, and date that we configure during deployment.
Common objections from the partner meeting
"We already have AI, Copilot respects our permissions."
Copilot respects the permissions on content Microsoft Graph indexes, and that guarantee is real. The gap is the half of the archive Graph never sees, and the stale-snapshot window on the half it does. In Corpus, access is trimmed by role before search, so restricted projects never reach the answer, and the mapping to the firm's existing permissions is set up during deployment across all three surfaces.
"You'd be copying our documents into another environment, that's a new attack surface."
Only if you choose our hardware, and we will not pretend otherwise: then the archive is ingested into a SalemWise-hosted, tenant-isolated environment, so the firm carries no GPU cost. If no copy may leave the building, Corpus runs on a local NVIDIA GPU on your network instead. When we host, four things bound the risk. The environment is isolated per firm. The model is an open-weight model we run, so nothing is routed to a public AI API or used to train an external model. The most sensitive material, sealed expert-witness work and conflict-walled matters, is excluded by a do-not-index list we build during setup, so it never arrives. And access is trimmed by role before search, so restricted projects never reach the answer. That is the trade when we host: you do not run the system, and in exchange the data-handling has to be airtight, which the free 30-minute call and the deployment reference architecture exist to prove before you commit.
"Does our archive get sent to an outside AI provider?"
No. Queries and the documents they retrieve are processed only by the open-weight model Corpus runs, on your hardware or ours. Nothing is sent to OpenAI, Anthropic, Google, or any third-party AI API, and nothing is used to train an external model. This is the architectural difference that lets a firm handling sealed or conflict-walled work use AI retrieval at all.
"How do we prove to the E&O carrier that the permission layer works?"
The audit trail we configure during deployment records which identity was authorized for which source on which date, and before rollout we test the conflict-wall rules against constructed leak tests. That artifact is what the broker asks for, and it is what a snapshot-based index cannot produce after the fact.
"What about a litigation hold that lands after we've indexed?"
Held documents go on a do-not-index list we build during setup and are removed from the index on the next permission resync. The hold scope is documented so preservation obligations are auditable.
What to do about this before your next renewal
Three actions. The first two cost nothing and can happen this week.
1. Ask your professional-liability broker one question. Does our policy now carry an AI exclusion, and is our CGL endorsed with ISO Form CG 40 47? If the answer is yes, or "let me check," you have just learned that an AI-provenance claim may fall into a coverage gap, which reframes every AI tool the firm runs as a liability question, not an IT one.
2. Pull one litigated or conflicted project and ask who can see the sealed documents in it. Have whoever administers your archive confirm which people can currently retrieve the walled-off files, then have an engineer run the test directly: from an account that should not have access, ask your existing AI tool to summarize one restricted document, move the document to a different folder, wait an hour, and ask again. If the restricted content still comes back, your index is serving stale permissions, which is the exact failure that generates the Friday call.
3. Book a free 30-minute call. We talk through your archive and how its permissions are set up, and tell you whether Corpus fits. Mapping your archive surfaces and identity setup, the library-by-library permission review and the quote for a 6–8 week deployment happen in the paid pilot or setup. No slide deck, and the first two actions above tell you whether you even need the call.
Talk through your archive. 30 minutes, free.
A free 30-minute conversation about your archive, its permissions and whether permission-aware AI search fits your firm. Mapping the archive and the quote for a 6–8 week deployment happen in the paid pilot or setup. Corpus runs on your hardware (a local NVIDIA GPU on your network) or ours, and you pay flat, not per seat.
Book a free 30-minute call See Corpus by SalemWise Try the live demoYermek Ibray, ex-Meta/Google, builds Corpus, page-cited AI search for engineering firms, at SalemWise Solutions. salemwise.com/contact
Sources cited in this article: Microsoft Learn (SharePoint indexer ACL preview) for the 2025-11-01-preview API behavior, the initial-indexing-only ACL capture, the stale-permissions failure mode, and the unsupported SharePoint group types; Microsoft Learn (SharePoint limits) for the 5,000 recommended / 50,000 hard-cap unique-permission limits per library; Microsoft Learn (manage permission scopes) for the inheritance-break error language; Microsoft Learn (Copilot data protection) for Copilot's query-time authorization model; Glean for its real-time permission-enforcement claim; Ames & Gough 2026 A/E PL Survey for the 73% rate-increase, 80%-AI-disruptor, and civil-engineering-second-severity figures and the Jared Maxwell quote; Cohen Seglias for the ISO Form CG 40 47 January 2026 generative-AI CGL exclusion. Related SalemWise reading: Microsoft 365 Copilot for Civil Engineering Firms and Deltek Dela for Civil Engineering Firms: Honest Review. Disclosure: Microsoft®, Microsoft 365®, Copilot™, SharePoint®, OneDrive®, Teams®, Microsoft Entra ID™, Microsoft Graph™, and Azure® AI Search are trademarks of Microsoft Corporation; Glean™ is a trademark of Glean Technologies, Inc.; ProjectWise® and Bentley® are trademarks of Bentley Systems, Inc.; Deltek®, Vantagepoint®, and Dela™ are trademarks of Deltek, Inc. SalemWise Solutions is not affiliated with, endorsed by, or sponsored by any of these companies. Pricing, API version strings, and insurance form designations are current as of May 2026 and may change; verify before relying on them.
