Dibs.software
A useful feature description says what goes in and what comes back.
The Dibs idea is deliberately small: let a person recognise an open time and ask for it without turning a simple sheet into a complicated business system. This feature guide separates actual shared computations from the experience described around them. Its workshop examples are fictional and manual. None creates a booking or demonstrates a live Dibs integration.
01 · Dibs.software
First come needs a defined acceptance point
A fictional adult ceramics group offers individual glaze demonstrations. Jules writes “first come, first served” at the top of a planning note. Pat asks what counts as coming first: seeing the notice, sending a message, receiving a reply, or having the organiser accept the request. The slogan alone does not settle that question. A dependable arrangement needs a point at which a request becomes an accepted allocation.
The shared fixed-slot decision evaluates supplied access and capacity inputs. It does not by itself provide the storage transaction or the customer confirmation that makes a completed claim durable. Jules revises the planning note: “Our current manual arrangement treats the organiser’s confirmation as the allocation; this is not a Dibs booking.” The output gives their fictional discussion a concrete acceptance point without claiming a product feature. The pause is to check whether that is actually the arrangement the organisers intend. The objection that speed should decide everything misses the practical issue: a system must decide what event it is measuring. A visitor’s impression that they were first is not an accepted result.
02 · Dibs.software
Capacity is a rule with inputs
A slot for one person and a session for three people need different capacity values. The shared fixed-slot function counts supplied bookings for the selected key and compares that count with the supplied capacity. It can therefore answer a narrow question about whether another booking fits those inputs. It does not inspect a room, measure working space, or decide how many people the demonstration can comfortably accommodate.
Pat’s first example has capacity one and one existing booking for the chosen key. The refusal follows from the supplied data. The second example uses a different key with no existing booking; that is a separate calculation, not an automatic offer to the original requester. Their worksheet records each key and count explicitly. The result is an explanation of why the two decisions differ. Jules pauses before carrying a number into a real invitation because a numerical limit is only useful when it reflects the actual arrangement. If someone asks whether Dibs can discover the right capacity automatically, that capability is not offered here. A sensible input still requires an organiser’s judgement and an actual operating workflow.
03 · Dibs.software
Access comes before the attractive answer
An open period does not necessarily mean that every caller is entitled to take it. In the shared core, access is a predicate supplied by the caller. A missing predicate or a result other than true produces an access refusal. The fixed-slot decision evaluates that condition before the capacity check. This is an actual branch order in the reviewed function, not a claim about every product or every route in the family.
For the adult worksheet, Jules uses two labelled hypothetical cases: an authorised request and an unauthorised request. Both refer to the same sample period, but only the first passes the supplied access condition. The result demonstrates why availability and permission are separate concepts. It does not create a membership list or establish who has permission in a real group. The pause is to avoid treating a label in an example as verified identity. Pat’s objection is that a sign-up sheet should feel welcoming. It can be welcoming while remaining clear that an invitation has a scope. This page neither administers that scope nor offers an access-granting action through a public form.
04 · Dibs.software
A time boundary does not supply travel or preparation
The time-window calculation can distinguish adjoining intervals from overlapping ones under its half-open rule. That supports a precise answer about the timestamps passed to it. It does not add travel time between buildings, inspect the length of a demonstration, or decide when equipment has cooled enough for another person. Those practical conditions need to be expressed in the arrangement rather than inferred from an empty space on a grid.
Pat writes a specimen with a demonstration ending at 14:20 and the next starting at 14:20. Mathematically they adjoin. Jules adds a separate preparation note because the adult workshop needs an interval for resetting materials. Their output is a revised manual plan with that gap shown explicitly. Nothing in the example synchronises a calendar or reschedules a participant. The pause is to compare the written plan with the intended activity. If an organiser objects that a calendar normally handles these details, a calendar may display a gap without knowing whether it is adequate. Dibs does not claim automatic travel, setup, resource readiness, or external-calendar reconciliation on this site.
05 · Dibs.software
Counts and labels need an honest status
A remaining count is useful because it answers a different question from a participant list. The Dibs design is for a reader to understand an opening without browsing other people’s names. That is a design boundary for the unavailable customer surface. The reviewed pure core accepts opaque references; this alone does not prove what every future page or feed would disclose. No Dibs public roster or subscription feed is offered here.
Jules sketches two sample labels: “one place shown in this example” and “full in this example.” Pat removes the names that had been pencilled beside them because the drawing’s purpose is to explain capacity, not identify attendees. The result is a better adult teaching illustration. It does not demonstrate a server projection or prove that a deployed endpoint strips fields. The pause is to keep the example label attached when the drawing moves into another document. If someone asks for a guarantee about a school roster, this adult feature exercise is not that clearance. Existing school-related design statements have their own limits, and this page creates no additional minor-data or consent procedure.
06 · Dibs.software
The unavailable parts remain unavailable
A friendly claim sheet, customer branding, self-serve access, and calendar connections are different pieces of an experience. The existence of shared scheduling code does not turn those pieces into a delivered Dibs product. There is no live customer sheet here, no checkout, and no AI selecting a period. A displayed feature description is not a licence, a purchase, or an account entitlement.
Pat finishes the comparison with two headings: “Relevant shared decision evidence” and “Actions this public site does not provide.” Under the first are the access and capacity computations discussed above. Under the second are publishing the group’s sheet, accepting a real claim, changing a stored reservation, and sending a participant notification through Dibs. The result lets Jules decide whether a product conversation is useful without presenting speculation as a procurement checklist. The pause is to check the status wording again before sharing the comparison with others. The objection that a feature page should only celebrate features is understandable, but availability is part of a feature’s meaning. A clear limit is more useful to an organiser than a long list that leaves them guessing which actions they can actually take.
Keep the next step clear
Contact Dibs.software for a human enquiry. This page does not create a sheet or accept a claim. Read the starting point and help page for the existing product status.