A gear inventory and a packing list do different jobs

An inventory and a packing list can contain some of the same names. That does not make them the same record.

An inventory answers what do I own? A packing plan answers what does this event need? The first describes available gear. The second describes demand for a real use. Treating them as one list makes it harder to see whether you have covered the plan or merely recorded an item.

Begin with the job in front of you

BorderKit does not require a complete inventory before planning can begin. You can add gear you own, build a reusable kit, or plan an event.

A kit or event can start with category requirements such as T-shirts ×3 or First aid kit ×1. You can link those requirements to specific owned gear when that detail is useful. The requirement remains the requirement: linking one shirt does not reduce the quantity needed, and it does not reduce the number of shirts recorded as owned.

This allows the gear inventory to grow as it becomes useful. It also keeps a plan honest when a category and quantity are enough to prepare with.

Give each record one clear job

The three records are related, but each owns different information:

• Owned gear records an item, including its stock quantity and current details.
• A kit is a reusable, purpose-driven plan. It can contain direct links to owned gear, category requirements, or both.
• An event is a planned real use. It carries its own requirements, linked kits, packing state and review history.

An event is not a template. It is the place where preparation meets the conditions of a particular trip, job or scenario. A kit provides reusable structure, while the event keeps the decisions that belong to that use.

Connect the records without collapsing them

When a kit is added or synced into an event, BorderKit copies the relevant gear and requirements into the event with their kit provenance. Event-side changes then stay with that event. They do not rewrite the source kit or sibling events.

Later kit changes do not silently alter an event either. An explicit sync preview shows what was added, removed or changed before local event decisions are overwritten. Reuse supplies a starting point without pretending that every use should stay identical.

The same boundary applies to owned gear. Resolving an event requirement links the plan to specific gear, but the event does not consume the inventory record or erase the original demand.

Keep active lists clear without losing context

When gear and kits are no longer active, they can be archived. They disappear from normal lists and pickers, but BorderKit retains the records needed to resolve historical references. Where an older event carries a completion snapshot, that snapshot takes precedence over later names or details.

The event lifecycle is separate. Archiving an event preserves its plan and makes it read-only until it is restored. Permanently deleting the event removes the event and its own entries and reviews.

Separating these jobs is not a demand to catalogue everything. It is a way to keep ownership, reusable preparation and a real event connected without asking one list to stand for all three.