Platform architecture

Reuse existing canonical objects where available.

Do not create Point Preserve-specific duplicates of general-purpose objects.

At minimum, evaluate whether the following objects already exist:

•Tenant

•Organization

•User

•Role

•Team

•Person

•Contact

•Vendor

•Location

•Property

•Unit

•Asset

•Project

•Task

•Checklist

•ChecklistItem

•Assignment

•Comment

•Artifact

•MediaAsset

•AudioAsset

•Transcript

•EvidenceSubmission

•Review

•Approval

•RevisionRequest

•RecurrenceRule

•Reminder

•Notification

•KnowledgeRecord

•SOP

•DecisionRecord

•AuditEvent

A minimal canonical Task object should support, directly or through references:

•id

•tenant_id

•organization_id

•project_id

•parent_task_id

•title

•description

•status

•priority

•task_type

•requester_id

•creator_id

•assignee_type

•assignee_id

•reviewer_id

•location_id

•asset_id

•vendor_id

•due_at

•started_at

•submitted_at

•verified_at

•closed_at

•source_artifact_ids

•checklist_id

•evidence_requirement

•safety_classification

•financial_approval_requirement

•recurrence_rule_id

•tags

•metadata

•created_at

•updated_at

•version

A canonical Evidence Submission should support:

•id

•tenant_id

•task_id

•submitted_by

•evidence_type

•artifact_id

•transcript_id

•description

•captured_at

•submitted_at

•location_reference

•integrity_metadata

•verification_status

•reviewer_id

•reviewed_at

•review_notes

•created_at

•updated_at

Do not force all fields into one table if the platform uses normalized linked objects.

Use existing conventions for IDs, tenancy, timestamps, soft deletion, versioning, provenance, and auditability.

Reuse or extend the canonical event registry.

Evaluate and define versioned contracts for events such as:

•source_artifact.received

•source_artifact.processed

•transcription.completed

•task.draft_generated

•task.created

•task.updated

•task.assigned

•task.accepted

•task.started

•task.blocked

•task.unblocked

•task.checklist_item_completed

•task.progress_updated

•task.evidence_attached

•task.submitted_for_review

•task.revision_requested

•task.verified

•task.reopened

•task.closed

•project.created

•project.status_changed

•knowledge.proposal_generated

•knowledge.approved

•knowledge.updated

•sop.proposal_generated

•notification.requested

•audit.event_recorded

For each event specify:

•canonical name;

•version;

•producer;

•intended consumers;

•required payload;

•optional payload;

•tenant and organization context;

•actor context;

•correlation ID;

•causation ID;

•idempotency behavior;

•retry behavior;

•privacy classification;

•retention expectations;

•compatibility policy.

Do not put full private file contents or unnecessary personal information into event payloads.

Use references to protected artifacts.

Voice is a first-class input method.

Implement or reuse support for:

•recording voice from supported interfaces;

•uploading existing voice memos;

•preserving the original audio file;

•transcription;

•speaker metadata when reliable and permitted;

•timestamps;

•AI extraction;

•transcript correction;

•linking transcript segments to proposed tasks;

•voice-based progress updates;

•voice-based completion reports;

•voice-based reviewer feedback.

Transcripts must remain editable or correctable by authorized users.

The system must distinguish:

•original audio;

•machine transcript;

•corrected transcript;

•AI summary;

•structured extraction;

•human-approved task.

Never destroy the relationship among these records.

Images must be usable as task input and task evidence.

Support workflows such as:

1.User uploads a photograph of a loose gate.

2.User says or types: “John, repair this before Friday.”

3.System preserves the image and instruction.

4.System proposes:

•title;

•description;

•assignee;

•due date;

•location;

•relevant asset;

•priority;

•checklist;

•required after-photo.

5.User reviews and confirms.

6.Assignee receives the task.

7.Assignee uploads progress and final evidence.

8.Creator or authorized reviewer reconciles and verifies it.

9.The completed repair updates asset and operational history.

10.A reusable lesson or procedure is proposed when appropriate.

Do not use visual inference to make unsupported claims about dangerous conditions, code compliance, structural integrity, electrical safety, or other professional determinations.

Such conditions should be flagged for qualified human review.

Integrate with the existing canonical identity and access model.

Do not create a separate Point Preserve authentication system.

Support configurable roles such as:

•property owner or administrator;

•operations manager;

•task creator;

•staff member;

•maintenance worker;

•vendor;

•reviewer;

•knowledge approver;

•read-only observer.

Permissions should control:

•task creation;

•task assignment;

•viewing private tasks;

•viewing vendor or financial information;

•uploading evidence;

•changing status;

•requesting revision;

•verifying completion;

•reopening work;

•deleting or archiving records;

•publishing knowledge;

•viewing audit history;

•accessing audio or sensitive attachments.

Enforce tenant isolation and least-privilege access.

Vendor access should be limited to the records necessary to complete authorized work.