CrossBeam AI FactSheet
Effective Date: July 13, 2026 Version: v1.0 Published by: Onboard Dot AI LLC (dba CrossBeam)
This FactSheet follows the GovAI Coalition's AI FactSheet format so that any public agency can use it directly in AI procurement review. It is written as a Developer FactSheet: CrossBeam is a standard software product we build and operate, not a bespoke professional service. We will complete the official GovAI Coalition template — or a city's own AI questionnaire, CAIQ, or HECVAT — on request. Where this document and our Privacy Policy both speak to a topic, the Privacy Policy governs the legal commitment; this FactSheet explains how the system works.
1. Overview
CrossBeam is an AI-assisted plan review platform for building departments. It reads a submitted set of construction documents against the governing building code and the city's adopted local amendments, and it drafts review comments — a corrections list, each item tied to the code section it comes from and the plan sheet it was found on.
The core design principle is simple and it does not change anywhere else in this document: AI drafts, humans approve. CrossBeam produces a draft. A licensed city plan reviewer reads it, edits it, and decides what goes into the official correction letter. The AI makes no binding determination and issues no permit. It is a first-pass reviewer that hands a head start to the human reviewer who is accountable for the result.
Operator: Onboard Dot AI LLC, a California limited liability company, doing business as CrossBeam.
2. Intended Purpose & Domain
Intended purpose. To accelerate and standardize the first pass of municipal building-permit plan review by drafting evidence-cited corrections for a city plan reviewer to verify and adopt.
Domain. Building-permit plan review for California cities (and, increasingly, other states), across any permit type that includes an architectural construction-document set — single-family residences, multi-unit residential, accessory dwelling units, and commercial tenant improvements among them. CrossBeam is not limited to any single permit type.
Intended users. City building-department staff (plan reviewers, permit technicians, building officials) and — through a city's submittal portal — the contractors, designers, and property owners who submit applications to that city.
Out of scope / not intended for.
- Making final or binding permit decisions. Every decision is made by city staff.
- Substituting for the professional judgment of a licensed architect, engineer, or building official.
- Use as the sole basis for any decision that "substantially impacts the rights or safety of individuals with no meaningful human oversight" — the category of use prohibited by the San Jose / GovAI AI policy. CrossBeam is built to be the opposite of that: advisory only, human in the loop by design.
- Real-time biometric identification, emotion recognition, social scoring, or any surveillance use. CrossBeam does none of these and processes no such data.
3. Model Information
CrossBeam is a multi-model system. Two kinds of model work together:
a) Reasoning model (LLM). The review reasoning — reading code sections, comparing them against what the plans show, and drafting the correction language — runs on large language models provided by Anthropic (Claude).
b) Vision model. Reading the pixels of a plan sheet — recognizing text, locating where an element sits on a drawing, and interpreting aerial and parcel imagery — is performed by a commercial vision AI model from an established provider.
Model versions are confidential and available under NDA. The specific model versions we run are part of how the product performs and are treated as proprietary. We disclose exact versions to a contracting city under the engagement, subject to confidentiality. This is the same disclosure line used in our Privacy Policy, which names our AI inference providers but not model versions.
Both providers are first-party US API services and are contractually barred from retaining or training on the materials we send them (see Section 4).
4. Training Data & Whether Customer Data Trains Models
We do not train models on customer data. This is a hard commitment, not a default setting.
- No training on submitted materials. We do not use the construction documents, drawings, calculations, or any submitted permit materials to train, fine-tune, or develop any AI or machine-learning model. Submitted materials are processed solely for inference — that is, to analyze that specific application and draft its review — and are then deleted on the schedule in Section 15.
- Subprocessors are contractually barred from retaining or using submitted materials for their own model training or development.
- We do not build our own foundation models. The reasoning and vision models are third-party commercial models used through their APIs. We do not fine-tune them on city data.
What CrossBeam is actually "trained" on — the knowledge base. The intelligence that makes CrossBeam accurate for a given city is not a trained model weight; it is a structured, human-auditable knowledge base built per jurisdiction from published law: the state building code (in California, Title 24) as the floor, plus each city's own adopted local amendments as a delta on top. This knowledge base is assembled from public, published sources — code text and city ordinances — and is maintained through a monitored update pipeline (Section 6). Because it is built from published law rather than from customer submissions, it contains no permit applicant's data.
5. Test Data & Validation
CrossBeam is validated per city, during onboarding — before that city goes live — in two distinct layers. It matters which layer a number describes.
Layer 1 — knowledge-base fidelity. The jurisdiction knowledge base (Section 4) is validated against the published law it encodes: we spot-audit what the knowledge base says against the state code and the city's adopted local amendments themselves, and a city is not promoted to production until it clears that audit gate. Disagreements are run down and corrected in the knowledge base rather than papered over. Bounded example (past tense): the Costa Mesa knowledge base was validated at 99.7% fidelity to the published code during onboarding (2026). That figure measures how faithfully the knowledge base encodes published law — it is not a claim that CrossBeam's review outputs are 99.7% correct, and CrossBeam makes no standing accuracy claim about review outputs.
Layer 2 — review-output testing. Before go-live we also exercise the review itself against test submittals with known issues — including deliberately failing and edge-case scenarios — to confirm the system finds what it should, cites the right code section, and does not invent corrections that do not apply. In production, the operative control is not a test score: a human reviewer verifies every finding before it becomes a correction (Section 14), and reviewer disagreement feeds back into the knowledge base (Section 18).
6. Update Procedure
CrossBeam is updated along two independent tracks, each with a gate before anything reaches a city.
a) Knowledge-base updates (the law changes). California publishes building-code errata and adopts new code editions on a schedule; cities amend their local codes. We run a monitored update pipeline that watches the authoritative sources — including the Building Standards Commission's Title 24 errata — detects changes, and revises the affected jurisdiction knowledge base. Changes are reviewed by a human before they are merged and take effect. Because the knowledge base is built from published law, every update is traceable to a public source.
b) Model updates (a new model version). When we consider moving to a newly released reasoning or vision model, the candidate must pass a fixed regression test battery before it is promoted to production. We hold the model constant in production until a replacement has demonstrably matched or beaten the incumbent on that battery. Models are never swapped into the live review path untested.
A city can request the current state of both tracks — the code editions and local-amendment date its knowledge base reflects, and confirmation that the production model has passed the current battery — at any time.
7. Inputs & Outputs
Inputs.
- A submitted set of construction documents (typically a multi-sheet architectural PDF: plans, elevations, sections, details, calculations, specifications).
- Basic project context: the permit type, the project address, and the jurisdiction.
- Address-derived context resolved from public data: parcel, zoning, and hazard-overlay information used to establish which code provisions apply.
Outputs.
- A draft set of review findings — a corrections list. Each finding cites two things: the governing code section it is based on, and the specific plan sheet (and location on it) that is the evidence. A finding that cannot point to both is not asserted as a correction.
- A draft corrections letter assembled from those findings, in a format a reviewer can edit and issue.
- A status and completeness read on the submittal.
Every output is a draft for human review. Nothing is transmitted to an applicant as an official city determination until a city reviewer has approved it.
8. Interfaces & Integrations
- Web application. City staff use CrossBeam through a browser-based application (dashboards, a findings viewer, and a review workspace).
- Submittal portal. Applicants can submit plans through a city-branded online portal.
- Single sign-on. City staff sign in with their own city Google or Microsoft (Azure AD) accounts via OAuth/OIDC — CrossBeam stores no separate password (see Section 16).
- Export and round-trip. Findings can be exported for use in a city's existing tools, including markup round-trip with common plan-review software, so CrossBeam fits into an existing workflow rather than replacing it.
- Chatbot and lookup. A permit-assistant chatbot answers code and status questions grounded in the same published-code corpus that drives review.
CrossBeam is designed to sit on top of a city's existing permitting system of record, not to replace it.
9. Performance & Monitoring
Monitoring. CrossBeam runs on managed cloud platforms (see Section 16) that provide continuous infrastructure monitoring and logging. Review jobs are tracked to completion; a job that produces no usable output is recorded as failed rather than silently passed, so a city reviewer is never handed an empty result presented as a finished review.
Accuracy monitoring. Each city is validated at onboarding — knowledge-base fidelity to published law plus review-output testing (Section 5) — and re-checked when the city's knowledge base or the production model changes (Section 6). A reviewer-feedback loop (Section 18) lets city staff flag any finding they disagree with, and those signals feed back into the knowledge base.
What we do not claim. We do not publish uptime, latency, or service-level numbers in this document, and we do not present standing accuracy figures. Performance commitments, if a city wants them contractually, are set in the service agreement. What we commit to here is the posture: managed, monitored infrastructure, human verification of every finding, and a validation gate before any city goes live.
10. Bias & Fairness
Building-plan review is a comparison of a drawing against a written code requirement — a domain where the right answer is anchored in published law, not in personal characteristics. CrossBeam is built to keep it that way.
- Findings are grounded in cited code, not in the identity of the applicant. Every finding quotes the governing code section and points to the plan-sheet evidence. The system is designed to reason about what the code requires and what the plans show — not about who submitted them.
- No sensitive or special-category data. CrossBeam does not collect or process protected characteristics (race, ethnicity, health, biometric data, etc.), so those attributes are not available to influence an output.
- Consistency across applicants. Because the same jurisdiction knowledge base and the same code-citation discipline apply to every submittal in a city, CrossBeam works toward more consistent treatment across applicants than ad hoc review, not less.
- Human backstop. A city reviewer verifies every finding, which is the ultimate check against any systematic error.
We do not claim CrossBeam is bias-free, and we welcome a city's own fairness review of our outputs; the evidence-citation design is what makes that review possible.
11. Robustness & Failure Handling
The central robustness rule: if the system cannot ground a finding in both a code section and plan-sheet evidence, it does not assert the finding — it flags the item for human review instead of guessing.
- Evidence-anchored by construction. A correction that cannot cite a governing code section and point to the sheet it was found on is not emitted as a correction. This is the primary defense against hallucinated or unsupported findings.
- Graceful degradation. When a submittal is incomplete, illegible, or outside the system's confident range, CrossBeam surfaces that as something for the human to look at rather than fabricating a confident answer.
- No silent failure. Review jobs that fail are recorded as failed, not completed. A reviewer is not shown an empty or partial result dressed up as a finished review.
- Human verification as the final control. Because every finding is checked by a city reviewer before it is issued, a model error becomes a caught draft edit, not a wrong decision sent to an applicant.
12. Optimal vs. Poor Conditions
Optimal conditions. CrossBeam performs best on complete, professionally drafted architectural construction-document sets — vector or clean digital PDFs with legible dimensioned drawings, standard sheet organization, and the calculations and specifications a full plan-check expects. This is the great majority of what a building department receives for the permit types CrossBeam covers.
Poor conditions. CrossBeam is less reliable on:
- Scanned, faxed, photographed, or handwritten legacy drawings where text and dimensions are degraded or illegible.
- Incomplete submittals missing the sheets or calculations a review depends on.
- Non-CD submittals — sketches, marketing renderings, or documents that are not a true construction-document set.
- Highly unusual or one-off scopes that fall outside the jurisdiction knowledge base's coverage.
In poor conditions the system is designed to flag its uncertainty for the human reviewer (Section 11) rather than overstate confidence. A city reviewer remains the decision-maker in every condition.
13. Explanations & Transparency
CrossBeam is built to be explainable at the level a reviewer actually needs: every finding shows its work.
- Each finding names the governing code section it rests on and links to the plan sheet and location that is the evidence for it. A reviewer can see why a correction was raised, check the cited code, and look at the cited sheet — without taking the system's word for it.
- The corrections letter is assembled from those traceable findings, so the reasoning is visible end to end rather than hidden in an opaque score.
- The jurisdiction knowledge base is built from published, citable law, so the basis for a requirement is always a public source a reviewer or applicant can look up.
This citation-first design is deliberate: it is what lets a human reviewer verify the AI's work quickly, and it is what makes CrossBeam auditable by a city.
14. Human Oversight
A human city plan reviewer makes every decision. CrossBeam never issues a permit or a binding determination.
- CrossBeam produces a draft. A licensed city reviewer reads, edits, and decides what becomes an official correction; the application then continues through the city's normal review and approval process.
- The AI's output is advisory and non-binding in every case, for every permit type. This is stated in our Privacy Policy and is enforced by the workflow itself — there is no path by which a CrossBeam output reaches an applicant as a city decision without a human approving it.
- This maps directly onto the one hard prohibition in the San Jose / GovAI AI policy — no fully automated decisions that substantially affect people without meaningful human oversight — and onto the "enhance staff, don't replace them" principle. CrossBeam is designed to give a reviewer a faster first pass, not to remove the reviewer.
15. Data Handling & Privacy
Our full commitments are in the CrossBeam Privacy Policy. In summary:
- Our role. When processing submittals for a partner city, CrossBeam acts as that city's service provider under the CCPA (Cal. Civ. Code § 1798.100 et seq.). The city remains the business; we process the data only for the purposes the city directs.
- No training on customer data. Submitted materials are used only to review that application and are never used to train or fine-tune any model (Section 4).
- Data residency — United States. Primary compute and storage run on US cloud infrastructure: backend compute on Google Cloud (us-central1), the primary datastore on Supabase/AWS (us-east-1), and the web application on Vercel. Our AI inference providers are first-party US API services.
- Retention. Submitted materials are deleted from CrossBeam systems 90 days after permit completion or withdrawal. A city may specify its own retention period, and a city independently keeps its own records under applicable records-retention law.
- No sensitive data. CrossBeam does not collect or process sensitive/special-category personal information (no government identifiers, financial-account credentials, health, or biometric data).
- No sale of data. We do not sell personal information, and permit data is never shared with advertising tools.
16. Security Posture
- Encryption. TLS in transit everywhere (HTTP redirected to HTTPS; no plaintext endpoints) and AES-256 at rest for the database and for uploaded plan storage.
- Tenant isolation. Every record is scoped to an organization and enforced by PostgreSQL Row-Level Security — one city's data is inaccessible to another at the database layer, not merely in application code.
- Authentication. Single sign-on via the city's own Google or Microsoft (Azure AD) accounts. City staff sign in with their existing city identities, so CrossBeam inherits the city's identity-provider and MFA policy and stores no separate password. Access is role-based (least privilege).
- Managed, SOC 2 infrastructure. CrossBeam's entire stack runs on SOC 2-certified managed platforms (Google Cloud, Supabase, Vercel, Cloudflare, and Google/Microsoft identity), which continuously patch the underlying stack, and we apply our own controls on top (RLS, TLS, encryption at rest, least privilege, no-training).
- Independent external rating. An independent BitSight external security rating of 700 ("Intermediate") was assessed in April 2026.
- Insurance. We maintain technology errors & omissions and cyber liability coverage, including affirmative AI coverage. A certificate of insurance is available to a city on request.
- Incident notification. We commit to notifying a city within 72 hours of a confirmed breach, enabling the city to meet its own notification obligations (e.g., Cal. Civ. Code § 1798.29).
We can provide a certificate of insurance, our subprocessor list, our Privacy Policy, and a completed security questionnaire (CAIQ/HECVAT) to a city's assessment team on request.
17. Jurisdictional & Regulatory Considerations
- Built jurisdiction by jurisdiction. CrossBeam's accuracy is a function of a per-jurisdiction knowledge base: the state code as the floor plus each city's adopted local amendments as a delta. It is designed to reflect the specific law of the specific city under review, not a national average. A city is only promoted to production after it clears the onboarding validation gates (Section 5).
- California and expanding. CrossBeam is live across many California cities and is expanding to additional states; the same build-and-validate discipline applies to each new jurisdiction.
- AI-governance alignment. CrossBeam is designed to satisfy the San Jose / GovAI Coalition AI-policy model that a growing number of California cities are adopting: advisory-only with meaningful human oversight, evidence-cited and auditable outputs, US data residency, no training on resident data, and no prohibited use (biometrics, social scoring, automated rights-affecting decisions). This FactSheet is itself the GovAI FactSheet artifact that model calls for.
- CCPA. CrossBeam operates as a CCPA service provider to cities (Section 15).
18. How to Flag Issues
- In-product reviewer feedback. City staff can flag or dismiss any individual finding they disagree with directly in the review workspace. Those signals are used to run down disagreements and improve the relevant jurisdiction knowledge base — the same loop that drives our validation methodology.
- Direct contact. Anyone — city staff or an applicant — can raise a question or concern about a specific AI-generated finding, or about how the AI analysis works, by contacting us at team@getonbreeze.com. A city can also route a concern through its normal CrossBeam support channel.
- Incident reporting. Suspected security incidents are handled under our incident-response process, with a 72-hour confirmed-breach notification commitment to the affected city (Section 16).
19. Accessibility
CrossBeam is a modern web application built with standard, semantic web components, which supports assistive-technology use of the interface. A formal WCAG 2.1 AA conformance assessment is planned, and we have not yet completed one; accordingly, this FactSheet does not assert formal WCAG conformance. We will share the results of that assessment when it is complete and will work with a city to address accessibility needs identified during its own review.
20. Responsible AI Strategy
CrossBeam's responsible-AI strategy is the product's core design, not a separate policy bolted on:
- Advisory-only, human-in-the-loop by design. AI drafts; a human city reviewer approves. No automated, rights-affecting decision without meaningful human oversight.
- Evidence over assertion. Every finding must cite the governing code section and the plan-sheet evidence; if it cannot be grounded, it is flagged for a human rather than guessed.
- Enhance staff, never replace them. CrossBeam gives reviewers a faster first pass and more consistent output; the reviewer's judgment and accountability remain central. This aligns with the workforce-empowerment principle in the San Jose / GovAI framework.
- Grounded in published law. The knowledge base is built from public state code and each city's adopted amendments, maintained through a monitored update pipeline — auditable and traceable to sources.
- No training on resident/customer data, US data residency, no sensitive-data collection, and no prohibited use.
- Validated before deployment, gated on change. Per-city validation before go-live — knowledge-base fidelity to published law plus review-output testing; a fixed test battery before any model is promoted.
- Transparent by publication. We publish this FactSheet and our Privacy Policy openly, and we complete a city's own AI and security questionnaires on request.
21. Contact & Document History
Publisher: Onboard Dot AI LLC (dba CrossBeam) Contact: team@getonbreeze.com AI FactSheet page: https://crossbeam-permits.com/ai-factsheet Privacy Policy: https://crossbeam-permits.com/privacy
| Version | Date | Notes |
|---|---|---|
| v1.0 | July 13, 2026 | Initial publication. Follows the GovAI Coalition Developer AI FactSheet format. |
We will update this FactSheet as the product and its jurisdictional coverage evolve, and we will complete the official GovAI Coalition template — or a city's own procurement questionnaire — on request.