Connect system intent to requirements—and give implementation the context it needs.

Generated with Ellygent’s definition-summary exporter. Proposed requirements and source IDs here are authored review notes in Additional Information; structured specification exports are separate.

# System Definition Summary

**Project:** Remote unlock — illustrative public sample

---

## Problem Statement

### Problem
Illustrative public sample — Let users unlock the door from the app.

### Current State
The feature request does not define authorization, failure behavior or confirmation.

### Impact
Developers would otherwise have to choose how to interpret request success.

### Context & Environment
A resident uses a mobile app, an access service and a connected door controller. Connectivity can fail between a request and physical actuation.

### Constraints
Accepting a request does not confirm physical unlocking. All requirements below are proposals for engineering review.

### Stakeholders
- Resident
- Access administrator
- Systems and software engineers

### Additional Considerations
- Sample revision: demo-v1; this is not a saved project baseline.
- Public example choices stay in this page and are not saved to a project.

## Mission Objectives

### 1. Give authorized residents remote access with an accurate reported outcome.
**Metric:** Compare the app’s reported outcome with the controller’s physical state in scenario tests.
**Target:** Never report Unlocked from request acceptance alone.

## Concept of Operations

### Actors
- **Resident** (human) — Requests access from the app.
- **Door controller** (system) — Actuates the lock and reports its physical state.

### Operational Domains
- Connected building access

### Environment Constraints
- Connectivity can fail during an unlock request.

### Scope: Included
- Remote request, authorization, lock actuation and outcome reporting

### Scope: Excluded
- Mechanical key access
- Emergency egress design

### Additional Information
Sample proposed requirements and source notes (authored review notes; not a specification export):

SYS-01 [System; proposed — engineering review required]: For a resident whose grant remains valid through dispatch, when the controller is online and accepts the command, the system shall actuate the lock and report its physical unlocked state for that request.
Sources: SCN-01; DEC-01, DEC-02.

SW-01 [Software; proposed — engineering review required]: The app shall display Unlocked only after receiving the controller’s physical unlocked-state confirmation correlated to the current request.
Sources: SCN-01; DEC-02; contributes to SYS-01.

SW-02 [Software; conditional draft — decisions pending]: When the controller is known to be offline, the access service shall reject the remote request without queuing a command, and the app shall display Device unavailable.
Sources: SCN-01; DEC-03; contributes to SYS-01.

SW-03 [Software; conditional draft — decisions pending]: If physical confirmation is absent 10 seconds after dispatch, the app shall display Outcome unknown and shall not automatically retry. Illustrative assumption: the 10-second timeout requires validation.
Sources: SCN-01; DEC-02, DEC-04; contributes to SYS-01.

SW-04 [Software; conditional draft — decisions pending]: Before dispatching an unlock command, the access service shall recheck the resident’s grant for the door and deny dispatch if the grant has been revoked. Post-dispatch revocation remains deferred.
Sources: SCN-01; DEC-01, DEC-05; contributes to SYS-01.

Open review question: How should late, duplicate or out-of-order controller reports be handled?

Deferred boundary: How should revocation after command dispatch be handled?

### Operational Scenarios

#### 1. SCN-01 · Remote unlock
**Goal:** Allow an authorized resident to enter.
**Trigger:** The resident selects Unlock in the app.
**Outcome:** An authorized resident gains access when the controller reports the lock physically unlocked. Request acceptance alone is not confirmation.

### Additional Considerations
- **[assumption]** DEC-01 · Authorization · resolved: Only a signed-in resident with an active grant for this door.
- **[assumption]** DEC-02 · Physical confirmation · resolved: A controller report of the physically unlocked state, correlated to this request.
- **[note]** DEC-03 · Offline behavior · unresolved: Unresolved: What happens when the device is offline?
- **[note]** DEC-04 · Confirmation timeout · unresolved: Unresolved: What happens when confirmation does not arrive?
- **[note]** DEC-05 · Access revocation · unresolved: Unresolved: What happens if access is revoked?

## System Capabilities

### 1. Remote door access
*An authorized resident gains access when the controller reports the lock physically unlocked. Request acceptance alone is not confirmation.*

**Trigger:** Resident requests Unlock

Available package structure inside .ellygent/. This is a file guide, not a generated ZIP for the public sample. Actual content depends on your project and export selection.

manifest.json

Project identifier, live version or baseline identifier, generation time and included content.

project-summary.md

Project overview and links into the selected context.

system-definition.md

Selected system-definition content. Record assumptions and open questions in the source content so they travel with it.

requirements/<specification>.md

Selected specification hierarchy, requirement identifiers, fields and readable relations. Filename depends on the specification.

relations.json

Machine-readable relations between exported objects.

traceability/relationships.json

Optional source-ID → relation type → target-IDs mapping, enabled with --include-traceability.

Sample traceability/relationships.json

Illustrative IDs and relation names in the supported JSON format. In a real project, these must be recorded relationships between elements; source notes in a summary do not automatically create links. A relationship can point to a decision that still needs review.

{
  "SYS-01": {
    "derives": [
      "DEC-01",
      "DEC-02",
      "SCN-01"
    ]
  },
  "SW-01": {
    "derives": [
      "DEC-02",
      "SCN-01"
    ],
    "satisfies": [
      "SYS-01"
    ]
  },
  "SW-02": {
    "derives": [
      "DEC-03",
      "SCN-01"
    ],
    "satisfies": [
      "SYS-01"
    ]
  },
  "SW-03": {
    "derives": [
      "DEC-02",
      "DEC-04",
      "SCN-01"
    ],
    "satisfies": [
      "SYS-01"
    ]
  },
  "SW-04": {
    "derives": [
      "DEC-01",
      "DEC-05",
      "SCN-01"
    ],
    "satisfies": [
      "SYS-01"
    ]
  }
}