product-concept

Mappm Product Concept

Use this skill for strategic Mappm planning that is broader than UI.

Read .codex/skills/ui-onboarding/SKILL.md first for current project context. Use github-issue when the result creates actionable follow-up work.

Boundaries

• Documentation and planning only.
• Do not write application code.
• Do not create low-level implementation plans; hand off to the relevant architect/builder skill.
• Do not use GitHub Issues to replace accepted decisions. Decisions belong in docs/technical/DECISION_*.md.

Normative Product Baseline

• Read docs/technical/DECISION_COMMERCIAL_CORE_SCOPE.md.
• Read docs/technical/DECISION_ACCOUNT_VAULT_ASSIST_PRODUCT_MODEL.md.
• Read docs/technical/DECISION_VAULT_STORAGE_AND_CLOUD_PRODUCT_MODEL.md.
• Read docs/concepts/CONCEPT_F36_VAULT_MODES_CLOUD_LIFECYCLE.md.
• Read docs/technical/DECISION_CASE_RELATIONSHIP_WORKFLOW_COMPOSITION.md.
• Read docs/technical/DECISION_CASE_FAMILY_DEFINITION_CONTRACT.md whenever a Case family, matching boundary, typical content or lifecycle is in scope.
• Read docs/technical/DECISION_MEDICAL_CARE_COST_SETTLEMENT_MODEL.md for the accepted medical Care/Cost/submission baseline.
• Read docs/technical/DECISION_ACCIDENT_DAMAGE_SETTLEMENT_MODEL.md whenever accident, damage, theft/loss, repair costs, insurance settlement, policy matching or medical consequences of an accident are in scope.
• Read docs/technical/DECISION_INSURANCE_SETTLEMENT_MODEL.md whenever an insurer, policy, submission/resubmission, external damage reference or insurance handling context is in scope.
• Read docs/technical/DECISION_CAPTURE_FIRST_ASSISTED_ROUTING.md.
• Read docs/technical/DECISION_INTELLIGENCE_SCOPE.md whenever OCR, LLM, extraction, matching, title, workflow suggestion, relation suggestion, document quality or automation is in scope.
• Read docs/concepts/CONCEPT_F38_ASYNC_PROCESSING_WAIT_EXPERIENCE.md whenever progressive extraction, background processing, wait animation or Review Queue behavior is in scope.
• Read docs/technical/DECISION_DESKTOP_IMPORT_SCOPE.md when desktop import, removable media, folder archives, ZIP handling or platform scope is affected.
• Read docs/technical/DECISION_CROSS_DEVICE_CAPTURE_HANDOFF.md when smartphone-to-desktop capture, Local-to-Local transfer or Continuity Camera is affected; it is a Draft and never authorizes implementation.
• Read docs/discovery/MEDICAL_CASE_MODEL_DISCOVERY.md only when medical Case rationale is in scope. It is a resolved non-normative reference, not authority for the accepted core.
• Read docs/technical/DECISION_INITIAL_CASE_WORKFLOW_CATALOG.md.
• Read docs/technical/DECISION_DOCUMENT_TYPE_CATALOG.md whenever a Case, workflow, document family, taxonomy or matching vocabulary is discussed.
• Read docs/technical/DECISION_RECURRING_CONTRACT_SUBSCRIPTION_MODEL.md.
• Read docs/technical/DECISION_MANAGED_SUBJECTS_BUSINESS_CONTEXTS.md.
• Read docs/technical/DECISION_JURISDICTIONAL_TAX_DOCUMENT_COLLECTION.md.
• Read docs/technical/DECISION_CONTEXTUAL_REVIEW_ACTIONS_FINANCIAL_ROLLUPS.md.
• Read docs/technical/DECISION_TEMPORAL_FACT_EVENT_AGENDA_MODEL.md whenever dates, events, deadlines, tasks, Agenda, extraction or calendar capability are affected.
• Read docs/technical/DECISION_RULE_DERIVED_DEADLINES_REMINDERS.md whenever a Country-/Provider-/Policy rule can derive a deadline or reminder.
• Read docs/technical/DECISION_AUSTRIA_MEDICAL_PAYER_RULE_PACK.md whenever Austrian medical payers, KFA, supplementary insurance, reimbursement deadlines or provider-specific submission behavior are in scope.
• Read docs/ops/OPS-09_COUNTRY_PROVIDER_RULE_MAINTENANCE.md whenever a Country-/Provider rule is proposed for activation, release or update.
• Read docs/execution/handoffs/DOMAIN_BACKEND_FEASIBILITY_REGISTER.md whenever product semantics depend on extraction, matching, latency, confidence, cost, privacy or target-release backend capability.
• Read docs/concepts/CONCEPT_F37_CASE_RECORD_CONTEXTUAL_EXPERIENCE.md.
• Read docs/discovery/OPEN_QUESTIONS_REGISTER.md; OQ-011 blocks final taxonomy, OQ-012 is resolved and OQ-013 blocks only Cross-Device-Capture convenience paths.
• Treat Local and Cloud as explicit Vault modes, not environment flags.
• Every normal Free/Paid Local and Cloud mode requires a Mappm Account; Local remains local-authoritative and Detached Recovery is the account-independent exit guarantee.
• Cloud Vault is managed-cloud-authoritative; local data is cache and pending work.
• Core Assist is required in Commercial Core and is separate from Vault authority; Assist processing never silently creates Cloud storage/backup.
• Every plan assumes only small to medium general-purpose model capability: coarse type/domain classification, OCR, type-dependent semantic field proposals, conservative title and best-effort ranking. Product/Document decisions define the few relevant review fields; Assist may prefill them with a top candidate and alternatives, but does not invent the field set or finalize semantic wrong-profile/case/document detection, page coherence, affected-person inference, workflow/legal-deadline meaning, causality or relationship truth. Stronger behavior needs a named class/release feasibility gate; user context and confirmation remain authoritative.
• Provider migration is explicit, verified and reversible through export/migration.
• Cancellation never causes immediate loss: grace/read-only, export, reactivation, Cloud-to-Local migration and deletion are distinct product states/actions.
• Home Hub is not a customer product. Local Development Cloud is synthetic developer infrastructure using the production contract family.
• The first target is a production-ready, sellable Commercial Core. Deferred features are absent rather than incomplete.
• Commercial 1.0 is Austria-first. The next planned expansion direction is the German-speaking market area, but every jurisdiction keeps separate legal, provider, source and release evidence; German language never selects jurisdiction. WF-01 still decides the exact Austrian Golden Workflows, WF-02 their professional ownership and WF-03 the post-Austria jurisdiction order.
• Mappm has one Case entity. A Subvorgang is only the UI role of a normal Case connected with CaseLink(relationType=part_of); there is no separate Subcase type or strict parentCaseId target tree.
• A Case is deliberately generic and may remain a lightweight named document collection/context. Custom/guided behavior, domain template and workflow are optional enrichments, not visible Case subtypes; never invent a large Case type picker.
• Every persisted Case is valid. Zero, one or many documents are allowed; no document type/set, workflow, task, submission or outcome is a general validity requirement. Assist proposals are not Cases until confirmed creation, and there is no invalid Case lifecycle state.
• Split workflow stages, tasks, events and branches from Cases by independent goal/lifecycle/outcome, not by sender, institution, document or local status. Composition is reversible and supports top-down and bottom-up creation without copying content.
• Guided, Assist-suggested and manual/Custom Cases have equal capabilities.
• Global capture always runs asynchronous Backend/Core Assist analysis and matching. Capture begins in a visible Managed-Subject context that may be preselected or inherited. Before leaving capture, the user may optionally supply only known information such as base type/useful subtype, confirmed facts, Managed Subject, coarse routing, new-Case intent or an existing Case. These are provenance-bearing hints, never mandatory fields, a replacement for matching or permission for Assist to overwrite user values. The service must propose editable titles for every logical Document and proposed Case/Record, including explicit new-Case intent. Automatic titles are conservative and contain no date by default. The accepted M1 exception is the contextual medical desktop media package: the user enters its required title manually and may add an optional examination date; the package is not unpacked for OCR/Assist.
• Current release routing is user-confirmed through relevant visible results; later reversible automation is class-specific, measured, abstaining and undoable. Mobile scan uses one explicit logical document per completed scan and each Desktop file is one initial logical document. Mixed content does not make the document invalid and is neither rejected nor auto-split in M1. unit, with multiple pages before Naechstes Dokument scannen. Batch/session proximity never proves a shared Case.
• Completed review requires a primary Case or Record. A lightweight Custom Case may begin with generated title, Managed Subject and optionally one document.
• Mappm has no Claim entity, repository or matching target. An independently tracked insurance handling context is a normal insurance_settlement Case; individual submissions/resubmissions are repeatable events or workflow steps. External claim/damage numbers are Facts and policies are Records.
• follow_up_to forms Case chains/branches without parent ownership. Medical baseline composition currently uses one neutral medical_care anchor, one part_of medical_cost_settlement per independently issued medical invoice/honorarnote and payer submissions as repeatable events/branches with zero, one or many document links. Corrections, credits, proof, submissions and payer responses for the same invoice stay in that Cost Case; a new independently issued invoice creates a new Cost Case. No document is required for Case validity. Treatment authorization documents stay inside Care and do not become Cases or M1 types. Reha, follow-up and later evidence are matched per document against existing and po

Content truncated.