Domains
Every domain has decisions the code cannot explain.
See how project context helps developers and AI agents recover the constraints behind five different systems before changing them.
Five fictional projects. Concrete questions, sample answers, and inspectable sources.
Banking
Preserve the decision behind the transaction.
Payment systems carry settlement windows, retry rules, and incident lessons that a refactor must respect.
Context to bring: decisions, specifications, and team lessons.
PROJECT / ATLAS PAYMENTS
Why does reconciliation run at 2am instead of on demand?
Answer grounded in 2 sample sources
Project context recovered
The provider finalizes settlement at 1:30am. The team reserved a 30-minute buffer before reconciliation reads the completed batch.
Before changing this: Preserve the settlement window and confirm the provider’s timing constraints.
ADR-014 · Reconciliation schedule
Sample excerpt: Run reconciliation at 02:00 after settlement. On-demand processing could read an incomplete batch.
Provider integration notes
Sample excerpt: Settlement completes at 01:30. Allow a 30-minute buffer before consuming the batch.
Illustrative workflow with fictional project data. No live query is sent.
Retail
Keep the promise behind the stock count.
Inventory logic reflects fulfilment commitments, seasonal demand, and decisions made after real operational failures.
Context to bring: decisions, specifications, and team lessons.
PROJECT / NORTHSTAR COMMERCE
Why do we reserve stock before payment completes?
Answer grounded in 2 sample sources
Project context recovered
The team introduced a ten-minute reservation after concurrent checkouts oversold limited stock. Payment confirmation converts that reservation into an allocation.
Before changing this: Keep reservation expiry and payment callbacks coordinated so the same stock cannot sell twice.
ADR-021 · Checkout reservations
Sample excerpt: Reserve available stock for ten minutes while payment is pending. Release expired reservations.
Flash-sale incident review
Sample excerpt: Concurrent payment-first checkouts oversold the same units. The corrective action was an atomic stock reservation.
Illustrative workflow with fictional project data. No live query is sent.
Enterprise
Recover the reason behind an approval step.
Internal platforms encode ownership boundaries, audit decisions, and exceptions agreed across teams.
Context to bring: decisions, specifications, and team lessons.
PROJECT / MERIDIAN PROCUREMENT
Why can’t the requester approve their own purchase order?
Answer grounded in 2 sample sources
Project context recovered
The procurement team separated request creation from approval after an internal controls review. Even a user with an approver role must route their own request to a second person.
Before changing this: Preserve the requester check when consolidating roles or simplifying the approval service.
Procurement approval policy
Sample excerpt: A purchase request must be approved by someone other than its creator, regardless of role.
Approval-service decision log
Sample excerpt: Retain the requester exclusion independently of the approver-role check. Route exceptions to the designated backup approver.
Illustrative workflow with fictional project data. No live query is sent.
Healthcare
Carry interface constraints into every change.
Clinical software integrations depend on local workflow decisions, identifier mappings, and handover agreements.
Context to bring: decisions, specifications, and team lessons.
PROJECT / CEDAR CARE INTEGRATIONS
Why do corrected lab results create a new version?
Answer grounded in 2 sample sources
Project context recovered
The integration team agreed to retain the original result and link each correction as a new version. The receiving system needs that history to distinguish a correction from a duplicate delivery.
Before changing this: Keep correction links and message identifiers intact when changing deduplication.
Lab interface specification
Sample excerpt: A corrected result references the original result identifier and carries a new version identifier.
Integration workshop notes
Sample excerpt: Preserve earlier versions. Do not overwrite the original result or discard corrections as duplicate messages.
Illustrative workflow with fictional project data. No live query is sent.
Manufacturing
Keep production rules tied to their rationale.
Planning systems rely on plant-specific changeover rules, equipment constraints, and lessons from previous production runs.
Context to bring: decisions, specifications, and team lessons.
PROJECT / FORGE PRODUCTION PLANNING
Why can’t the scheduler group these two batches together?
Answer grounded in 2 sample sources
Project context recovered
The plant team requires a cleaning cycle between these material families. The scheduling rule came from a quality review, even though both batches use the same equipment.
Before changing this: Retain the material-family changeover rule when optimizing machine utilization.
Changeover matrix · Line 3
Sample excerpt: Insert a cleaning cycle when switching between material families A and B on Line 3.
Quality review · Batch carryover
Sample excerpt: The team traced carryover to a skipped cleaning cycle. Scheduling must enforce the approved changeover matrix.
Illustrative workflow with fictional project data. No live query is sent.
Start with one team question
Keep the answer available after the conversation ends.
Choose one decision your developers repeatedly have to rediscover. We will map the shortest path to a licensed evaluation.