Security, AI and Trust

1. Security approach

JengaFlow treats project information as operationally sensitive. The platform uses authenticated access, password hashing, role checks, project-level authorization, request validation, controlled file handling, webhook authentication and operational logging.

Connections to the public service use HTTPS. Hosting, database, file-storage and communications providers maintain their own infrastructure controls. JengaFlow reviews application behavior and dependencies but does not claim a security certification that has not been independently awarded.

2. Access and project boundaries

Users receive roles and project assignments. Sensitive operations require an authorized role, and project access is checked before protected records are returned or changed. Administrators are responsible for accurate assignments and prompt removal of people who leave a project.

WhatsApp messages are accepted for project processing only when their group or authorized sender is explicitly connected under the configured bot policy. Unlinked groups are not intended to create project records.

3. AI transparency and human review

AI-assisted functions may read submitted text or images, extract construction fields, classify information, summarize records or flag possible inconsistencies. Deterministic calculations and validation rules are used where exact arithmetic or project boundaries matter.

Models can still misread handwriting, photographs, dates, quantities or context. Source evidence, confidence information and correction workflows should be used before accepting an output.

• AI output is a draft or decision-support signal, not structural certification.
• It does not replace statutory inspection, professional engineering judgment or a safety clearance.
• It does not independently approve valuations, payments, employment actions or contractual instructions.
• Authorized users remain responsible for final review and approval.

Specific checkpoints in the product today:

• Daily reports built from WhatsApp stay drafts. Before one can be submitted, someone with access to the project confirms which block and floor each photo belongs to, because software cannot reliably tell from the picture.
• Daily, weekly and monthly reports are approved only by the customer's project administrators.
• Each report built from WhatsApp keeps the messages it came from, so a figure can be checked against who sent it and when.

Whether customer content may be used for model improvement depends on the configured provider terms and customer agreement. JengaFlow should not use customer project data for unrelated model training without an appropriate legal basis and clear agreement.

4. WhatsApp-connected reporting

When an organization connects a project WhatsApp group, relevant messages, sender identifiers, images and documents may leave WhatsApp and be processed or stored by JengaFlow and configured providers. Group participants should receive a clear notice before collection begins.

Bot response modes and authorized groups are administratively controlled. Customers should use dedicated project-reporting groups where practical and avoid submitting unrelated personal conversation.

WhatsApp transport protections do not mean submitted project content is inaccessible to JengaFlow or the providers required to process it. See the Privacy Notice for data categories and rights.

Incoming WhatsApp messages are held in a processing queue for up to 14 days and then deleted automatically. The messages a report was built from, up to the last ten per report and 4,000 characters each, stay with that report for as long as the report is kept.

5. Shared customer responsibilities

• Assign only the access each person needs and review it regularly.
• Use accurate project-to-group mappings and remove obsolete WhatsApp connections.
• Notify workers, visitors and subcontractors about relevant data collection.
• Review extracted records against their source evidence.
• Keep emergency, statutory inspection and safety procedures outside dependence on a single online service.
• Report suspected account compromise or cross-project exposure promptly.

6. Accessibility

The public website is designed toward WCAG 2.2 Level AA practices, including keyboard navigation, visible focus, semantic structure, text alternatives, responsive layouts, light and dark contrast, and reduced-motion support.

This is not a claim of independent WCAG certification. If a page or workflow prevents access, report the affected URL, device and assistive technology so it can be investigated.

7. Security and accessibility reporting

Do not include passwords, access tokens, unnecessary personal data or exploit details in an ordinary support message. Security reports will be acknowledged and handled according to severity.