What is built, and where twins are applied

Summary

The evidence half of the pack. It leads with the S3-compatible vault container as the estate's one shipped twin and explains why it is the right exhibit: the consuming code is unmodified, the redirection is an endpoint change, and the same face sits over a vault, local disk, memory or real S3. It then covers the AWS twins in the IAM configuration risk engine, with the context-not-configuration principle that separates a twin application from a scanner, maps nine applications of the primitive across the estate with their owner sites, and labels the world-model layer as design.

Key concepts

• The working twin — the S3-compatible vault container
• Context, not configuration — a public bucket is a fact, not a problem, until you know what it holds
• The application map — nine applications, each with an owner site
• Facts from twins, judgement elsewhere — the grounding ladder as a pipeline

Key ideas

• Code using boto3, the AWS CLI, or any S3 SDK believes it is talking to real S3, and the service's own code does not change.
• The existence of a configuration is never itself a risk.
• This site owns the primitive; the applications mostly live elsewhere, which is the right shape for a reference site.
• Visualisation is not a feature you add later but where you start, and likely the first revenue stream.
• Every action is version controlled and every connection is mapped by folders and files without a database.

On this site

The source of what is built and the application map, with its world-model section on the simulation page.

Read the document