Discover

Discovery is where modelARch learns the product before it tries to implement it. The goal is not to produce a polished brief quickly; it is to expose the decisions that determine whether the software will be correct.

What discovery captures

A complete discovery usually covers:

• purpose: the problem and desired outcome;
• actors: who participates, what they want, and what they may access;
• structure: central objects, identities, values, and relationships;
• behavior: actions, events, lifecycle transitions, and rejections;
• rules: invariants, calculations, and eligibility conditions;
• read side: questions, lists, reports, and computed values;
• processes: multi-step work, handoffs, timing, and branches;
• external systems: capabilities, callbacks, failures, and ownership;
• experience constraints: channels, density, locale, and specialized needs.

A co-thinker, not a transcription service

The discovery expert should challenge ambiguity, contradictions, and missing negative cases. Useful questions include:

• What prevents this action?
• Who owns this record after creation?
• Is this a state transition or a separate object?
• What happens when the provider times out after accepting the request?
• Which actor needs to see this result, and at what scope?
• Does “delete” mean erase, cancel, archive, or make inaccessible?

A discovery that only repeats the user’s nouns will generate a data-entry system, not the intended product.

Lines, probes, and decisions

Treat each open topic as a line of reasoning. A probe explores a specific uncertainty; a decision closes it or explicitly parks it. This makes progress inspectable without reducing discovery to a percentage guessed by an AI.

When you reject an inferred behavior, record the decision. A structurally unchanged model may otherwise derive the same concern again—for example, whether a relationship intentionally has no cascade.

The readiness gate

Generation readiness is based on model structure and unresolved mandatory concerns, not on conversational confidence. The gate should block when a missing decision would force the generator to invent behavior or create a known safety issue.

Examples include missing ownership scope, unbound required data, unresolved mutation targets, and invalid references. Warnings may describe quality opportunities; errors and mandatory gaps must be fixed or explicitly decided.

Good input

Prefer concrete operational examples:

A receptionist can reschedule any appointment in her clinic. A patient can only cancel their own appointment, and only more than 24 hours before it starts. If payment authorization already exists, cancellation must request a refund and remain pending until the provider confirms it.

This single statement contains actors, scope, time rule, state, integration behavior, and an asynchronous consequence.

Crossing into design

Discovery is ready when the product has enough explicit structure to design and generate without silent invention. Crossing creates a ratchet: later edits can reopen questions, but the project does not forget that its initial discovery threshold was crossed.

Next, design the product experience or inspect the modeling concepts discovery creates.