Simulated data, labelled at every step.

The repository includes simulated sources, a simulated agentAgentA program that takes actions for an organisation. NovusLens records what it is allowed to do and what its activity reports show. estate and Meridian GridMeridian GridThe fictional demonstration organisation used by the demonstration walk and its sample data. Nothing about Meridian Grid describes a real company., a fictional demonstration organisation. They let the product be built, tested and shown before a customer hands over credentials. This page says what each simulated part is, how its output is labelled, and how to tell simulated evidence from real evidence wherever it appears.

What it is for

A demonstration that uses real-looking data can be mistaken for a measurement of a real organisation. NovusLens records the simulation label in the data itself. A simulated sourceSourceA document, interview statement, measurement or export that supports a value. Each source has a date and a stated scope. declares itself in every response. The acquirersAcquirerA program that reads a customer's operational records, calculates quantities from them and records the results in NovusLens. read that declaration and write it into the data they store. The product then shows the label next to the number. Simulated evidence is still shown, because the demonstration needs it, but it always says what it is.

Simulated evidence demonstrates the product. It is not evidence of how any customer performs.

Meridian Grid

Meridian Grid is a fictional demonstration organisation. Its teams, services, tickets, incidents, metrics, cloud resources and documents are invented to exercise the product. The fixturesFixtureA prepared set of records used for a test or demonstration. A fixture is sample data, not a live customer's records. that describe it are named with the meridian_ prefix in apps/connectors/fixtures/, for example meridian_servicenow_incidents.json, meridian_ticket_mapping.json and meridian_prometheus_metrics.json. The screenshots across these docs show Meridian Grid, and each one says so in its caption.

A group of two Meridian twins in two regions, Meridian Holdings, is also fictional.

The ticket mapping for Meridian Grid shows the shape a customer authors, with groups such as Forecasting Service Desk mapped to a capabilityCapabilityWhat a team can provide or an agent can do. NovusLens records the claim and the evidence that supports it.. Copy the shape, not the names.

Development examples

The commands below run fixture servers from a development checkout with the connectorsConnectorSoftware that reads records from a source system, such as an incident tool. A customer-written file connects those records to teams or services in NovusLens. package installed. They are for integrators rehearsing a source separately from the Docker installation. Use the Docker Operations manual to connect the installed twinTwinNovusLens’s model of one organisation, built from records about its teams, services and how they rely on one another. It is only as current as those records. to a reachable source.

The simulated sources

The simulated sources are small HTTPHTTPHypertext Transfer Protocol: the rules a browser or program uses to send a request to a web service and receive its response. servers that speak the APIAPIApplication programming interface: a defined way for one program to request data or actions from another. shape of one real system and serve one fixture. They are started with:

./lens exec -- python -m conway_connectors.sim_sources --fixture <fixture.json> [--port 8600]

They cover ServiceNow, Jira, Prometheus, GitHub Actions and PagerDuty. The default port is 8600. The same acquirers read simulated and real systems. Moving to a real system changes the URL, token and customer mapping. Connectors cookbook describes the acquirers.

The simulated estate

The simulated estateSimulated estateA set of example agents supplied for testing and demonstrations. Their findings carry the label “(simulated estate)”. Real customer reports do not carry that label. is a set of running agents on their own gatewayGatewayA service that accepts requests and passes them into another system. The Mycelium gateway gives NovusLens access to the mesh., standing in for a customer’s estate. It is started with:

./lens exec -- python -m conway_connectors.sim_estate --port 8410 [--cycles N]

The default port is 8410. It publishes a boundary feedBoundary feedRecords supplied by the customer’s own systems about activity at the edge of an agent or service. NovusLens reads those records; it does not watch the agent., which the read-only boundary subcommand reads. The demonstration estate has four example agents with repeatable behaviour. One declares delegated authorityAuthorityWhat a team or agent is allowed to decide or do. For an agent, this comes from a named person or system that grants permission. without an accountable ownerAccountable ownerThe person recorded as answerable for a team, service or agent. NovusLens does not assume that this person is also the one who runs it day to day. and acts beyond its declaration. Two have owners and stay within their declarations. The fourth publishes a changed AgentFactsAgentFactsA signed statement from an agent about its allowed work, its permissions and the person answerable for it. document whose signatureDigital signatureA check calculated with a signing key that can detect whether a record has changed. Identifying the signer also requires a trusted link between that key and its owner. fails; intake refuses it. Their behaviour is written to show the product’s findingsFindingA difference in the records that needs a decision. It includes its sources and can describe a slow handoff, disputed fact or missing owner., not to describe any real agent.

The estate identifies itself as novuslens-demo-estate.

The simulated network flow

A simulated flow export declares itself with a marker record, or, for VPCVPCVirtual private cloud: a private network defined inside a cloud provider's infrastructure. files, a # x_novuslens_simulated: true comment line. The network-flow acquirer propagates that declaration into every entry, the same way the other acquirers do.

How the label propagates

Simulation is marked at the source and carried through each stage:

The acquire command prints the label in its output. A simulated run reports SIMULATED source (the entries say so), so the label appears on the terminal as well as in the data.

The governance code keeps three kinds of input apart. Prepared example measurements, marked synthetic, are illustrative and are described as such in the finding text. The live feed of the simulated estate is marked estate: simulated. A real customer’s measurement carries neither marker. The code states that neither of the first two can pass as a real customer’s measurement.

How to tell real from simulated

Look for the label, then check the source.

• A real entry’s source is the kind and host of a real system, with no suffix. Its synthetic field is false, or absent.
• A simulated entry’s source ends in (simulated source), and the acquire command reports it as simulated.
• A finding from a simulated estate reads (simulated estate).
• A finding from prepared example measurements says it is shown from illustrative boundary telemetry, not customer performance evidence.
• A case in agent evidence has an environment of simulated, production or unknown. It is simulated if any source behind it is enrolled as simulated, and production only when every source behind it is production.

A real source that carries the marker is labelled simulated, because the label follows the declaration. If you see simulated data without its label, report it as a defect.

What simulated evidence may and may not be used for

Use simulated evidence to demonstrate the product, rehearse connections and test source readers and findings. It may not be presented as a measurement of a customer, quoted as performance evidence, or used to support a claim about a real organisation. A demonstration that shows simulated evidence should say so on the same page.