Open Mercato Resource Planning and Booking Boundaries

Capability and evidence vocabulary

• available
• configurable
• custom
• integration-required

• latest public release
• current develop
• current first-party documentation
• specification or plan
• external primary requirement
• editorial recommendation

Not established in reviewed evidence describes an evidence conclusion. The capability model still has four states.

Fifteen terms that must stay separate

Unavailable, allowed, and committed are different states

Record the source, timestamp, range, quantity, authority and confidence before showing a user-facing result.

• 1. Unavailable by a current rule
• 2. Rules allow the time; booking state remains unknown
• 3. Free or booked only after the authoritative commitment ledger is checked

The merged planner window reports what availability rules allow. It does not show whether the resource is free after commitments, holds, confirmations, payments or physical-access conditions. Translate dostępny as niezarezerwowany only after checking the authoritative ledger.

Current resource record and module boundary

Classify as metadata, control, reference or timestamp; assign purpose, editor, reader, validation, retention and acceptance.

• 1. Name and description
• 2. Optional resource type id
• 3. Positive-integer capacity metadata
• 4. Capacity-unit value
• 5. Capacity-unit name
• 6. Capacity-unit color and icon
• 7. Resource icon and color
• 8. Active state
• 9. Availability-rule-set id
• 10. Tenant and organization scope
• 11. Created and updated timestamps
• 12. Soft-deletion timestamp
• 13. Types
• 14. Tags
• 15. Custom fields
• 16. Comments
• 17. Activities
• 18. Attachments, search and version history

The default application separately registers planner and resources from @open-mercato/core, and resources declares planner as a dependency. Both are MIT licensed and ejectable in current source. Every downstream deployment must still verify that the modules are enabled and configured. The default registry describes only the reviewed application. Resource types are scoped categories and tags are flexible labels. Neither defines inherited booking policy. Comments, activities, attachments, message previews, search and history provide operational record surfaces. They do not provide maintenance, DMS, messaging or compliance systems.

Capability matrix inventory

Assign one shared capability state, evidence label, reviewed surface, revision and date, limitation, confidence, operational owner and next acceptance action.

• 1. Resource master records
• 2. Resource types
• 3. Tags
• 4. Custom attributes
• 5. Capacity metadata
• 6. Capacity-unit snapshot
• 7. Active and soft-delete lifecycle
• 8. Comments
• 9. Activities
• 10. Attachments
• 11. Message-object preview
• 12. Search
• 13. Version history
• 14. Tenant and organization scope
• 15. Resources access features
• 16. Planner access features
• 17. Availability rule sets
• 18. Weekly availability
• 19. Date-specific availability
• 20. Blocking unavailability
• 21. Merged allowed windows
• 22. Optimistic configuration locks
• 23. Guarded configuration mutations
• 24. Booking aggregate
• 25. Atomic collision prevention
• 26. Capacity consumption
• 27. Public booking channel
• 28. Approvals and waitlist
• 29. Check-in and no-show
• 30. Payment and order coupling
• 31. Calendar synchronization
• 32. Specialist-system integration

Capacity accepts a positive integer and stores a snapshotted unit label and presentation. Reviewed code does not reserve, decrement, sum or enforce it. A value such as 12 spots is metadata and cannot safely sell or assign pooled units without an atomic allocation model.

Runtime evidence defines the booking boundary

First-party documentation calls resources reservable items and names one-off reservations as a date-specific example. Current runtime records a date-specific availability or unavailability exception. It does not provide a booking identity, customer, quantity, status, collision decision, cancellation lifecycle or reconciliation record. Such an exception may manually block time associated with an external commitment. The external or custom ledger remains authoritative.

The shared AvailabilityRulesEditor has an optional loadBookedEvents extension hook. The reviewed resource detail caller does not provide it, so booked events are not loaded there. A component seam, translation string, unused constant, seed example, stale demo /booking endpoint and search snippet supply no shipped booking feature for this revision.

Recurrence and civil time need a narrow acceptance claim

• DTSTART
• DURATION
• DAILY frequency
• WEEKLY frequency
• Optional COUNT
• Exception dates and day-level one-off overrides

The reviewed merge helper recognizes this narrow RRULE-shaped subset, uses UTC-oriented parsing and fixed 24-hour or seven-day arithmetic, and handles one-off overrides at day granularity. The validator accepts a non-empty timezone string; IANA identifier validation is not established there. The reviewed helper does not implement full RFC 5545 recurrence, arbitrary calendar import/export, CalDAV behavior, universal DST correctness or cross-calendar interoperability. Treat these as acceptance risks. The reviewed evidence supports no conclusion about a defect or guarantee.

Define local intent, stored instant, expected occurrences, cancellation identity, evidence, owner and pass criterion in the deployed runtime.

• 1. DST forward: missing local time
• 2. DST back: duplicated local time
• 3. Start or end at midnight
• 4. Cross-date interval
• 5. Leap day
• 6. Multiple display zones
• 7. UTC versus local-time intent
• 8. Recurrence edit after occurrences
• 9. Cancellation exception identity
• 10. IANA timezone-data update

RFC 5545 · IANA time zone data

Editorial booking aggregate blueprint

This editorial implementation model describes project work. It does not describe current Open Mercato behavior. Fit the aggregate and lifecycle to the actual domain, authority and collision consequence.

• Requested
• Held
• Awaiting approval
• Confirmed
• Checked in
• Completed
• Cancelled
• Expired
• Rejected
• No-show

Name system of record, primary id, version, update mechanism, owner, latency target, reconciliation rule and exception owner.

• 1. Availability-rule state
• 2. Booking state
• 3. External-calendar state
• 4. Order state
• 5. Payment state
• 6. Notification state
• 7. Physical-access state

Collision prevention must commit atomically

For an exclusive resource, validate active competing commitments and write the new commitment in the same transaction or equivalent atomic control. For a capacity pool, sum active demand and commit the new quantity under the same protected boundary. A check followed later by a write can race. Current optimistic locks on resource and availability configuration reduce lost configuration edits; they do not arbitrate two booking requests because the reviewed booking write does not exist.

Specify parallel setup, idempotency, lock boundary, permitted outcome, prohibited duplicate or over-capacity result, recovery, reconciliation and evidence.

• 1. Two parallel exclusive bookings
• 2. Concurrent aggregate demand over capacity
• 3. Retry with the same idempotency key
• 4. Retry with a different key
• 5. Hold expiry versus confirmation
• 6. Cancel versus confirm
• 7. Booking update versus resource delete
• 8. Series change versus occurrence exception

OWASP business-logic race guidance

Define booking policies explicitly

Classify as configurable, custom or integration-required with authority, version, enforcement point, exception and acceptance evidence.

• 1. Setup buffer
• 2. Cleanup buffer
• 3. Lead time
• 4. Booking horizon
• 5. Minimum duration
• 6. Maximum duration
• 7. Booking increment
• 8. Blackouts
• 9. Cancellation window
• 10. Approval
• 11. Waitlist
• 12. Check-in
• 13. No-show
• 14. Recurring series
• 15. Series exceptions
• 16. Reassignment
• 17. Overbooking rule
• 18. Walk-in handling

Unused API constants, translation text, demo surfaces and search snippets do not define default duration or buffers.

A public channel is a separate product and risk surface

Name owner, evidence, abuse case, failure, correction, retention and stop condition. No reviewed public booking page or customer appointment flow is established in planner/resources.

• 1. Internal operator booking
• 2. Public or self-service page
• 3. Authentication and requester identity
• 4. Rate limiting and anti-abuse
• 5. Privacy and data minimization
• 6. Accessibility
• 7. Consent and terms
• 8. Customer communication
• 9. Payment and refund handoff
• 10. Support and correction path

System-of-record tree and external integration

1. 1

   Can Open Mercato own the domain-specific booking lifecycle and atomic collision control?

2. 2

   If yes, build and accept a custom aggregate before calling slots free

3. 3

   If no, keep the specialist scheduler authoritative

4. 4

   For hybrid use, assign authority per field and state

5. 5

   Reconcile every exception and provide manual recovery

A one-way calendar feed does not create conflict-safe two-way booking. Two-way sync needs identity, version or sequence, organizer and attendee rules, privacy projection, recurrence and exception identity, deletion and tombstones, origin and loop prevention, collision ownership, retry and reconciliation.

Availability access controls do not cover booking approval

Current staff-registered availability resolution distinguishes manage-all from linked-member self service; API keys do not receive that self-service branch, and missing staff resolution fails closed. These controls cover availability writes. They do not provide requester identity, booking approval, branch or resource ownership, separation of override authority, public access or cross-organization sharing.

Responsibility matrix

Assign responsible, accountable, consulted and informed roles, exception owner, backup, evidence and release authority.

• 1. Resource master data
• 2. Availability and recurring rules
• 3. Overrides and exceptions
• 4. Booking policy
• 5. Booking operations
• 6. Collision and capacity exceptions
• 7. Customer support and correction
• 8. Calendar and specialist integrations
• 9. Privacy and sensitive data
• 10. Release acceptance and rollback

A composite job that requires both a person and a room, vehicle or equipment needs one shared commitment boundary or a compensating design. Person availability, leave, time and workforce authority stay with the staff guide; stock quantity and warehouse reservation stay with the inventory guide.

Sensitive-data register

Define purpose, allowed reader and editor, retention, correction, deletion and export, search and log exposure, encryption evidence, downstream copy and owner.

• 1. Descriptions and free text
• 2. Access instructions or codes
• 3. Serial numbers and vehicle details
• 4. Maintenance and incident data
• 5. Requester or customer references
• 6. Booking purpose
• 7. Organizer and attendee data
• 8. Calendar and physical-access metadata

Reviewed planner/resources source defines no module-specific default encryption map. The reviewed source does not show whether the generic platform, custom-field policy, attachments, infrastructure or overlays encrypt the deployment. Verify each source. Never put secrets, access codes, health details or unnecessary personal data in free text.

Three synthetic architectures

Record current evidence, architecture choice, system of record, risk, owner, acceptance cases, stop conditions and next discovery step.

Poor fit without verified specialist authority

• Hotel PMS and channel management: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Healthcare or regulated appointments: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Workforce rostering and timekeeping: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Finite-capacity APS or MRP: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Field-service dispatch: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Fleet telematics: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Enterprise desk booking: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• CMMS or EAM: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Seat inventory and ticketing: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Rental contracts and damage management: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.
• Public marketplace: missing domain lifecycle, policy, collision, capacity, safety, integration or evidence controls; Open Mercato may hold selected references or orchestrate bounded steps only.

Stop or go factors

Name threshold, authority, current evidence, missing control, owner and mandatory stop condition.

• 1. Collision consequence
• 2. Public channel exposure
• 3. Payment or refund dependency
• 4. Regulated or sensitive data
• 5. Physical safety consequence
• 6. Existing calendar estate
• 7. Recurrence and timezone complexity
• 8. Volume and concurrency scale

Conditional go-live pack

Require evidence, owner, exception, recovery and conditional sign-off. This pack provides no score or certification.

• 1. Enabled planner and resources modules
• 2. Resource taxonomy owner
• 3. Capacity semantics
• 4. Authoritative commitment ledger
• 5. Atomic exclusive-resource write
• 6. Atomic capacity-demand write
• 7. Idempotency and retry
• 8. Hold expiry worker and recovery
• 9. Policy versioning
• 10. Timezone identifiers
• 11. IANA timezone-data maintenance
• 12. DST and recurrence acceptance
• 13. Access and denied combinations
• 14. Public-channel anti-abuse
• 15. Privacy and retention
• 16. Calendar loop prevention
• 17. Dead-letter and exception queue
• 18. Reconciliation
• 19. Customer correction path
• 20. Payment and order handoff
• 21. Monitoring and alerting
• 22. Backup and recovery
• 23. Rollback
• 24. Manual continuity plan
• 25. Conditional owner sign-off

Acceptance pack

Specify setup, concurrent actors, abstract ids, state sequence, expected authoritative and local evidence, prohibited outcome, failure injection, correction, reconciliation, owner and pass criterion.

• 1. Draft route isolation
• 2. Module registry refresh
• 3. Resource create and scoped read
• 4. Resource type and tag behavior
• 5. Capacity stays metadata
• 6. Availability weekly window
• 7. Date-specific allowed override
• 8. Date-specific blocker
• 9. Booked-event caller remains absent
• 10. Documentation wording qualification
• 11. DTSTART and DURATION
• 12. DAILY and WEEKLY recurrence
• 13. COUNT boundary
• 14. Exception date
• 15. DST forward
• 16. DST back
• 17. Midnight
• 18. Leap day
• 19. Multiple zones
• 20. Recurrence edit
• 21. Exclusive parallel request
• 22. Capacity parallel request
• 23. Same idempotency key
• 24. Different retry key
• 25. Hold expiry
• 26. Cancel versus confirm
• 27. Update versus delete
• 28. Series exception race
• 29. Resource optimistic conflict
• 30. Availability optimistic conflict
• 31. Cross-organization denial
• 32. Manage-all availability
• 33. Linked-member self service
• 34. API-key self-service denial
• 35. Missing resolver fail closed
• 36. One-way calendar boundary
• 37. Two-way version and loop
• 38. External delete and tombstone
• 39. Recurring exception mapping
• 40. Composite person and room commit
• 41. Public authentication
• 42. Public anti-abuse
• 43. Accessibility
• 44. Sensitive-data minimization
• 45. No module encryption overclaim
• 46. Reconciliation exception
• 47. Manual recovery
• 48. No JavaScript
• 49. Print and export
• 50. Local-only privacy sentinel

Stop conditions

• No commitment-ledger owner.
• No atomic collision design where collisions matter.
• Capacity meaning is unknown.
• No timezone and recurrence acceptance.
• No correction and cancellation owner.
• No integration reconciliation.
• No public-channel abuse controls.
• Sensitive data has no purpose or owner.
• Safety or regulated requirement lacks specialist authority.
• No acceptance evidence.

Source ledger and correction path

Evidence label, claim surface, revision or date, limitation and review owner recorded on 2026-07-14. Report corrections with the exact claim and replacement evidence.

• 1. Current develop module registry and planner/resources runtime
• 2. First-party resource documentation with broader reservable wording
• 3. v0.6.5 public release and current post-tag changes
• 4. RFC 5545 iCalendar standard for the broader recurrence boundary
• 5. IANA time zone data for civil-time maintenance context
• 6. OWASP business-logic guidance for atomic check-and-commit

Latest reviewed public release · Immutable resources source · Immutable planner source