Skip to main content
Security & trust

Governed construction intelligence starts with trust

Ezelogs is built on role permissions, tenant boundaries, audit trails, and governed AI — recommendations are explainable and human-approved.

No third-party attestation, federal authorization, or health-data compliance claim is made on this page unless independently verified.

Trust posture

How Ezelogs treats trust

Trust is a function of permissions, boundaries, evidence, and human control — not a marketing badge.

Role permissions

Roles follow your org chart — owners, GCs, subs, suppliers, finance, safety, field, admin.

Tenant boundaries

Company, project, and partner data live behind tenant boundaries with no cross-tenant blending.

Auditability

Signal → recommendation → human decision → action is captured and reviewable.

Governed AI

AI proposes; humans approve. High-risk workflows require explicit approval.

Human approval

No autonomous-action workflows. Approvals always live with the responsible human role.

Evidence-backed recommendations

Every recommendation surfaces the underlying records it was derived from.

Governance boundaries

What is separated, and how

Ezelogs treats company, project, role, AI, and admin boundaries as distinct surfaces — not overlapping pools.

CompanyProjectRoleAIAdmin

Company data

Tenant-bounded by default. Cross-tenant sharing only via explicit, audited agreements.

Project data

Project access mirrors the project participants — owner, GC, subs, suppliers, AEC, consultants.

Role access

Roles control what users can read, edit, approve, and export.

AI actions

AI proposes recommendations; it does not execute high-risk actions without human approval.

Admin controls

Admin actions are scoped, logged, and reviewable — including configuration changes.

AI governance

How AI behaves inside Ezelogs

AI is a participant inside a governed workflow — not an autonomous operator.

AI proposes

Recommendations are surfaced to the responsible role, not executed silently.

Humans approve

High-impact actions require explicit human approval before they take effect.

Explainable

Recommendations show the signals and records they were derived from.

Auditable

Every recommendation, approval, and action is captured for review.

High-risk gating

Cost, schedule, contractual, and safety-impact actions are gated behind review.

Tenant controls

Conservative multi-tenant posture

Tenants are bounded. No cross-tenant blending in recommendations or analytics surfaces.

Logical tenant isolation

Tenant identifiers scope every read, write, and recommendation.

Tenant-scoped credentials

API credentials and integrations are scoped to a tenant, not shared globally.

Explicit cross-tenant sharing

Cross-tenant collaboration (e.g., owner ↔ GC ↔ sub) is opt-in, scoped, and audited.

No cross-tenant model training

Tenant data is not used to train cross-tenant models without explicit, written consent.

Auditability evidence trail

Signal → recommendation → human decision → audit trail

Every governed recommendation can be traced from its source signal to the human who approved it.

1

Signal

Operational signal observed (RFI, cost, schedule, observation, submittal).

2

Recommendation

AI proposes an explainable recommendation tied back to the underlying records.

3

Human decision

The responsible role reviews, approves, modifies, or declines the recommendation.

4

Audit trail

The signal, recommendation, decision, and resulting action are recorded for review.

Security proof rows

Claim → evidence → status

Security statements should map to operating practice or independent verification — not marketing language.

Role-aware access enforced across product surfaces
Internal access-control review
Reference the role taxonomy and the surfaces it governs.
Tenant boundaries enforced by default
Internal architecture review
Document the scoping pattern for prospects and auditors.
Audit trails for AI recommendations
Product instrumentation
Show a redacted sample audit trail in security review.
Service-organization controls attestation (Type II)
Independent attestation required
Do not list as a claim until the attestation report is in hand.
Federal cloud authorization
Independent authorization required
Remove from public surface until authorization is achieved and documented.
Health-data compliance framework
Independent assessment required
Only list when scoped, assessed, and contractually offered.

Security posture statements describe current operating practice. Formal third-party attestations or certifications are listed only when independently verified.

Security FAQ

Common questions from procurement, IT, and security reviewers

Conservative answers. Anything that requires independent verification is flagged for Cursor review.

No. AI proposes recommendations; the responsible human role approves before action.

Role-aware access mirrors construction-industry org structure — owners, GCs, subs, suppliers, AEC, finance, safety, field, admin.

Each recommendation is explainable, traces back to its source records, and is captured in an audit trail.

Tenants are bounded by tenant identifiers across reads, writes, and recommendations. No cross-tenant blending.

High-risk workflows — cost, schedule, contractual, and safety-impact actions — require explicit human approval.

Any reference to third-party attestations, federal authorizations, or health-data compliance frameworks must be independently verified before public use.
Security review

Bring your security review questions. We will answer the way auditors expect.

Sandbox does not list certifications. Cursor wires verified attestations on merge.