This commit is contained in:
@@ -0,0 +1,135 @@
|
||||
# System infrastructure and lifecycle analysis
|
||||
|
||||
Use this method when a cross-client registry needs per-system answers for hosting location, system kickoff, and latest production release.
|
||||
|
||||
## Scope boundary
|
||||
|
||||
Keep these facts in canonical **system-level metadata**, separate from client-observation rows:
|
||||
|
||||
- Client rows prove that one organization owns, operates, uses, procures, or depends on a system.
|
||||
- System metadata describes the unique system as a whole.
|
||||
- A client's adoption date, tenant hosting arrangement, or modernization project must not become a shared-system fact unless the source explicitly applies it to the system globally.
|
||||
|
||||
Generated system dossiers remain derived views and must never become editable evidence stores.
|
||||
|
||||
## Required fields
|
||||
|
||||
Every unique system record should contain all three fields, even when unknown:
|
||||
|
||||
1. `hosting_environment`
|
||||
- known models: `cloud`, `on-premises`, `hybrid`
|
||||
- record the named provider or environment when the source states it
|
||||
2. `kickoff_date`
|
||||
- original system delivery or implementation start
|
||||
- precision: `year`, `month`, or `day`
|
||||
3. `latest_release_date`
|
||||
- latest directly evidenced production release or deployment
|
||||
- precision: `year`, `month`, or `day`
|
||||
|
||||
Allowed status values are `known`, `unknown`, and `not-applicable`. Unknown and not-applicable values require a concise reason. Known values require direct evidence.
|
||||
|
||||
## Evidence object
|
||||
|
||||
For each known value, preserve at least:
|
||||
|
||||
```json
|
||||
{
|
||||
"url": "https://official.example/source",
|
||||
"title": "Official source title",
|
||||
"quote": "Exact text supporting the asserted value"
|
||||
}
|
||||
```
|
||||
|
||||
The quote is a claim guard: it makes reviewers check whether the source really says *production hosting*, *kickoff*, or *release*, rather than merely mentioning a nearby date or technology.
|
||||
|
||||
## Meaning of the fields
|
||||
|
||||
### Hosting environment
|
||||
|
||||
Accept only explicit production placement evidence. A source may identify a commercial cloud, government cloud, private cloud, institutional data centre, supplier data centre, on-premises deployment, or hybrid arrangement.
|
||||
|
||||
Do not infer hosting from:
|
||||
|
||||
- DNS, IP ownership, TLS, CDN, or public website hosting;
|
||||
- eligibility for centralized IT/cloud services;
|
||||
- a supplier's generic AWS/Azure/GCP capability;
|
||||
- a SaaS product name without an institution/system-specific hosting statement;
|
||||
- development, test, backup, or disaster-recovery infrastructure when production is not identified.
|
||||
|
||||
### System kickoff
|
||||
|
||||
Use the original system-delivery or implementation start only when the source describes it as commencement, start, kickoff, or equivalent. Do not silently substitute:
|
||||
|
||||
- tender publication;
|
||||
- contract signature;
|
||||
- funding approval;
|
||||
- public launch;
|
||||
- modernization start;
|
||||
- project completion.
|
||||
|
||||
If only a later modernization kickoff is known, keep the original system kickoff unknown and preserve the modernization date in its proper project/observation context.
|
||||
|
||||
### Latest production release
|
||||
|
||||
Use an explicit production release, deployment, go-live, or version release date. A dated official announcement whose title/body explicitly says the system **started operating**, **launched**, **went live**, or was **deployed to production** may use the announcement's stated publication date as the release date: the operational statement establishes the event and the official date anchors it. Prefer the earliest authoritative announcement when corroborating reposts differ by a day, preserve all corroborating sources, and do not treat a later repost as a later release.
|
||||
|
||||
Do not substitute:
|
||||
|
||||
- a webpage updated or publication date when the body does not explicitly establish production operation;
|
||||
- contract end or project completion;
|
||||
- acceptance date unless the source also proves production deployment;
|
||||
- latest tender or maintenance contract date.
|
||||
|
||||
## Identity-safe canonical storage
|
||||
|
||||
Prefer a canonical metadata file keyed by the registry's stable system ID and include the underlying identity key as a guard:
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": 1,
|
||||
"systems": {
|
||||
"SYS-XXXXXXXXXX": {
|
||||
"identity_key": "name:canonical identity",
|
||||
"hosting_environment": {"status": "unknown", "reason": "...", "evidence": []},
|
||||
"kickoff_date": {"status": "unknown", "reason": "...", "evidence": []},
|
||||
"latest_release_date": {"status": "unknown", "reason": "...", "evidence": []}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Require exact coverage of all generated system IDs. Missing records must fail validation rather than silently defaulting to unknown, because omission and researched-but-unknown are different states.
|
||||
|
||||
When aliases, normalization, or client-scoped labels change, generated IDs may change. A bootstrap helper may add missing unknown skeletons, but it must:
|
||||
|
||||
- never overwrite researched values;
|
||||
- stop on stale IDs;
|
||||
- require manual evidence migration for merges and splits;
|
||||
- preserve the `identity_key` check.
|
||||
|
||||
## Validation rules
|
||||
|
||||
Fail generation/build when:
|
||||
|
||||
- metadata IDs differ from generated registry IDs;
|
||||
- an identity key does not match;
|
||||
- any required field is absent;
|
||||
- a status or hosting model is outside its controlled vocabulary;
|
||||
- a known value lacks a direct HTTP(S) source, title, or quote;
|
||||
- an unknown/not-applicable value lacks a reason;
|
||||
- a date does not match its declared precision;
|
||||
- generated JSON omits the analysis fields or retains an old schema version.
|
||||
|
||||
Publish canonical metadata as a byte-identical raw artifact with a checksum. Include the analysis in machine-readable registry JSON and generated system pages.
|
||||
|
||||
## Research rotation
|
||||
|
||||
A recurring research job should, for every unique system touched in a client batch:
|
||||
|
||||
1. Search explicitly for production hosting, original kickoff, and latest production release.
|
||||
2. Open and classify every candidate source.
|
||||
3. Update only directly supported fields.
|
||||
4. Preserve explicit unknowns for the rest.
|
||||
5. Regenerate, validate, build, inspect the complete diff, and verify published page and JSON output.
|
||||
|
||||
Initial migration should create explicit unknown records for full coverage. It must not mine existing prose automatically and turn nearby cloud or date mentions into system-level facts.
|
||||
Reference in New Issue
Block a user