# Historical Constituent Reconstruction

> Rebuild the Roster Without Looking Ahead

`D02-F04-A01` · Corporate Actions and Security Master Data → Point-in-Time Universe · archetype `record-transform` · difficulty 4/5 · verification **verified**

Full page: https://docs.thefintechbuilder.com/corporate-actions-and-security-master-data/point-in-time-universe/historical-constituent-reconstruction/
Agent skill: `npx skills add IslamBaraka90/Fintech-Algorithms-Library` — https://docs.thefintechbuilder.com/guides/agent-skill/

## Install and import

```bash
npm install fintech-algorithms
```

```ts
import { calculate } from "fintech-algorithms/corporate-actions-and-security-master-data/point-in-time-universe/historical-constituent-reconstruction";
```

## Signature

```ts
calculate(data)
```

Rebuilds an index's membership as it stood on a past date, from a base snapshot plus the change events since. Testing a strategy on today's members instead guarantees flattering results, because today's members are the survivors.

## Parameters

| Name | Type | Required | Notes |
| --- | --- | --- | --- |
| `data` | `{ indexId: string; effectiveAt: string; knownAt: string; snapshots: Snapshot[]; events: Event[] }` | yes | `effectiveAt` is the date whose roster you want; `knownAt` is when you are asking. They differ whenever a membership change is announced before it takes effect, or corrected afterwards — and conflating them is the bias this exists to prevent. |

## Returns

`{ status, indexId, effectiveAt, knownAt, baseSnapshotId, securityIds, membershipIntervals, … }`

The roster with the interval each member was in the index, and which snapshot it was rolled forward from.

## Errors

- When no snapshot precedes effectiveAt — reported as a status rather than thrown

## Complexity

Time `O(events)`, space `O(members)`.

## Worked example

This is the worked example published in the article, replayed by the test suite on every run. The output cannot drift.

### Input

`data`:

```json
{
  "indexId": "IDX:SYNTH:ALPHA",
  "effectiveAt": "2024-08-15T00:00:00Z",
  "knownAt": "2024-08-15T12:00:00Z",
  "snapshots": [
    {
      "snapshotId": "BASE-2024",
      "indexId": "IDX:SYNTH:ALPHA",
      "revision": 1,
      "effectiveAt": "2024-01-01T00:00:00Z",
      "availableAt": "2024-01-02T09:00:00Z",
      "lastSequence": 0,
      "status": "active",
      "securityIds": ["SEC:A", "SEC:B", "SEC:C", "SEC:D"],
      "sourceId": "SYNTH-BASE"
    }
  ],
  "events": [
    {
      "eventId": "EV-001",
      "indexId": "IDX:SYNTH:ALPHA",
      "revision": 1,
      "sequence": 1,
      "eventType": "add",
      "effectiveOrder": 0,
      "effectiveAt": "2024-02-01T00:00:00Z",
      "announcedAt": "2024-01-15T12:00:00Z",
      "availableAt": "2024-01-15T12:05:00Z",
      "status": "active",
      "changes": [
        {
          "action": "add",
          "securityId": "SEC:E"
        }
      ],
      "sourceId": "SYNTH-NOTICE-001"
    },
    {
      "eventId": "EV-002",
      "indexId": "IDX:SYNTH:ALPHA",
      "revision": 1,
      "sequence": 2,
      "eventType": "replace",
      "effectiveOrder": 0,
      "effectiveAt": "2024-03-01T00:00:00Z",
      "announcedAt": "2024-02-20T16:00:00Z",
      "availableAt": "2024-02-20T16:03:00Z",
      "status": "active",
      "changes": [
        {
          "action": "delete",
          "securityId": "SEC:B"
        },
        {
          "action": "add",
          "securityId": "SEC:F"
        }
      ],
      "sourceId": "SYNTH-NOTICE-002"
    },
    {
      "eventId": "EV-003",
      "indexId": "IDX:SYNTH:ALPHA",
      "revision": 1,
      "sequence": 3,
      "eventType": "rebalance",
      "effectiveOrder": 0,
      "effectiveAt": "2024-04-01T00:00:00Z",
      "announcedAt": "2024-03-20T15:00:00Z",
      "availableAt": "2024-03-20T15:04:00Z",
      "status": "active",
      "changes": [],
      "sourceId": "SYNTH-NOTICE-003"
    }
  ]
}
```

### Call

```ts
calculate(data)
```

### Returns

object with 4 fields: status, securityIds, appliedEventVersions, cancelledEventIds

```json
{
  "status": "resolved",
  "securityIds": ["SEC:E", "SEC:F", "SEC:G", "SEC:H", "SEC:I", "SEC:J"],
  "appliedEventVersions": ["EV-001@1", "EV-002@1", "EV-003@1", "EV-004@1", "EV-005@1", "EV-006@1"],
  "cancelledEventIds": []
}
```

## Verification and provenance

Tier: **verified** (via input-expected).

The worked example below is the figure published in this algorithm's article, replayed and asserted by the test suite on every build. The arithmetic cannot drift without the build failing.

Both tiers guarantee the signature. Full explanation: https://docs.thefintechbuilder.com/guides/verification/

Generated from the docs.json payload shipped inside fintech-algorithms@0.13.1.
The signature and parameter list are checked against the compiled implementation at build time,
so a description that contradicts the code fails the build rather than reaching this file.

## Links

- Article (how it works, step by step): https://thefintechbuilder.com/corporate-actions-and-security-master-data/point-in-time-universe/historical-constituent-reconstruction/
- Implementation source: https://github.com/IslamBaraka90/Fintech-Algorithms-Library/blob/main/src/corporate-actions-and-security-master-data/point-in-time-universe/historical-constituent-reconstruction/impl.ts
- Package on npm: https://www.npmjs.com/package/fintech-algorithms
- Domain index for agents: https://docs.thefintechbuilder.com/corporate-actions-and-security-master-data/llms.txt