Skills & CAPE

Implement the following five skills as the initial release.

Each skill must include a clear CAPE mapping, capability dependencies, user stories, interfaces, events, permissions, acceptance tests, and observability requirements.

Purpose: Allow tasks and projects to begin from nearly any reasonable human-provided source.

Supported inputs should include, where technically possible:

•live voice entry;

•uploaded audio or voice memo;

•typed text;

•image upload;

•multiple images;

•video attachment;

•PDF;

•office document;

•plain-text file;

•exported Apple Note;

•Apple Note containing references to embedded audio or other attachments;

•email-derived content;

•receipt, estimate, invoice, inspection report, or vendor document;

•existing project or task template;

•mobile camera capture.

Required behavior:

1.Preserve the original artifact.

2.Record source type, file metadata, creator, tenant, timestamp, and provenance.

3.Generate a transcript for supported audio or video.

4.Generate a structured extraction proposal.

5.Identify possible tasks, project context, location, asset, requested completion date, priority, responsible party, materials, safety concerns, and evidence requirements.

6.Present low-confidence or ambiguous interpretations for human review.

7.Allow one artifact to create:

•one task;

•multiple tasks;

•a project with child tasks;

•a knowledge-only record;

•no action, if the user rejects extraction.

8.Preserve links between the source artifact and all derived records.

Do not claim native direct access to Apple Notes unless a supported connector or export path exists.

Design an adapter-based ingestion architecture that can support:

•manual export;

•share-sheet upload;

•file upload;

•future Apple integration;

•future email and cloud-drive connectors.

Embedded Apple Note audio must be retained or referenced when present in the supplied export format. If the source format does not expose the audio file, record the limitation rather than implying successful extraction.

Purpose: Convert unstructured requests into accurate, editable, canonical work records.

Required behavior:

•classify task type;

•determine whether the item is a task, project, issue, recurring maintenance item, inspection, purchase, approval, or informational note;

•propose a clear title and description;

•extract explicit instructions without adding unsupported details;

•identify owner, requester, reviewer, due date, priority, location, asset, unit, vendor, dependencies, and expected evidence;

•generate a proposed checklist when appropriate;

•identify duplicate or related open tasks;

•identify possible safety, access, privacy, or financial concerns;

•suggest an existing SOP or project template;

•calculate confidence for material AI-derived fields;

•require human confirmation for consequential assignments, deadlines, financial commitments, or safety-related actions;

•preserve the original wording alongside the structured interpretation.

The AI may recommend. It must not silently create unsupported commitments.

Purpose: Help responsible parties perform the work and keep the record current.

Required functionality:

•personal and team task lists;

•project task boards;

•assignment and reassignment;

•task acceptance;

•status changes;

•configurable statuses;

•checklist execution;

•progress notes;

•voice progress updates;

•photo and video progress evidence;

•material or supply needs;

•vendor coordination notes;

•dependencies and blockers;

•due dates and reminders;

•recurring tasks;

•comments and mentions;

•change history;

•mobile-friendly quick actions;

•offline-tolerant capture where feasible;

•notifications through existing canonical communication services.

Suggested baseline task lifecycle:

DRAFT → READY → ASSIGNED → ACCEPTED → IN_PROGRESS → BLOCKED → SUBMITTED_FOR_REVIEW → REVISION_REQUESTED → VERIFIED → CLOSED

Do not hard-code this lifecycle if an existing canonical workflow engine can model it.

Use the platform workflow service and tenant-configurable state machines when available.

Purpose: Make completion provable rather than merely asserted.

The system must support:

•before photographs;

•after photographs;

•voice explanation;

•video;

•receipts;

•invoices;

•vendor documentation;

•checklist completion;

•measurements;

•timestamps;

•location references when permission and policy permit;

•reviewer comments;

•revision requests;

•approval or verification;

•completion exceptions;

•evidence completeness indicators;

•evidence integrity metadata;

•immutable audit history for material status changes.

The task creator should be able to reconcile the completed work unless permissions or policy assign that responsibility to another reviewer.

Reconciliation must allow the reviewer to:

•approve completion;

•request revision;

•clarify what remains incomplete;

•add a final note;

•accept completion with an exception;

•reopen a closed task, if authorized;

•confirm whether the result should generate or update knowledge.

Checking a box must not automatically equal verified completion when evidence or review is required.

Purpose: Convert completed work into operational memory.

After verification, the system should determine whether the work contains reusable knowledge.

Potential outputs include:

•SOP;

•maintenance procedure;

•troubleshooting note;

•vendor note;

•asset history;

•location history;

•project summary;

•lesson learned;

•parts or materials record;

•cost observation;

•seasonal maintenance guidance;

•recurring checklist;

•safety note;

•decision record;

•approved template.

Required behavior:

1.Generate a proposed knowledge summary.

2.Link it to the task, project, evidence, location, asset, people, and source artifacts.

3.Preserve provenance and confidence.

4.Require human approval before publishing material as canonical knowledge when the knowledge governance policy requires it.

5.Detect potential duplication with existing knowledge.

6.Update an existing knowledge record rather than creating a near-duplicate where appropriate.

7.Maintain version history.

8.Distinguish:

•raw evidence;

•AI-derived summary;

•human-approved operational knowledge;

•canonical SOP or policy.

Do not allow unverified AI summaries to masquerade as approved operational procedure.

Design these as compatible extensions, but do not allow them to delay the useful Phase 1 release.

Purpose: Identify work that may need attention before a person explicitly creates a task.

Possible capabilities:

•recurring maintenance recommendations;

•overdue-pattern detection;

•repeat repair detection;

•seasonal preparation suggestions;

•unresolved issue detection;

•duplicate task detection;

•asset failure pattern detection;

•project risk alerts;

•missing-evidence alerts;

•workload and bottleneck alerts;

•suggested task creation from approved operational rules.

Proactive intelligence must generate recommendations or draft tasks.

It must not automatically create costly, dangerous, or externally binding work without an approved policy and human control.

Purpose: Allow authorized users to ask natural-language questions about Point Preserve operations.

Examples:

•When was the pool heater last repaired?

•What vendor handled the previous gate repair?

•What materials were used?

•How much did the last similar project cost?

•Which tasks are still waiting for Heather’s review?

•What work has John completed this month?

•Has this issue happened before?

•What did we learn from the prior repair?

•Which recurring maintenance items are due next?

•Show the evidence for the last completed inspection.

Answers must be permission-aware, source-grounded, and linked to the underlying records.

Clearly distinguish retrieved facts from AI-generated conclusions.