From a source system to an observation, without guessing.

The 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. only knows what it has been told, shown or measured. Two packages feed it. conway_connectors (in apps/connectors) reads the customer’s own systems and writes observations. conway_meaning (in apps/meaning) keeps what documents say about the organisation. It checks for differences between those statements and the measured graphGraphA model made of units and links between them. In NovusLens it records teams, services and their dependencies..

What it is for

Every figure in NovusLens traces back to a source. 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. are where that trace begins: tickets give dependencyDependencyA link where one unit needs something from another. A dependency is not a reporting line: it shows where work relies on something else. lead timesLead timeThe elapsed time between starting a request or handoff and completing it.. Metrics give cellCellA box on the map that stands for a team, service, supplier or AI agent. It is a unit you can inspect, not necessarily a department or a person. C/A/RC/A/RThree separate scores for a team or service: Complexity, Agility and Recoverability. Each uses current evidence and the customer’s stated scoring rules. (Complexity, Agility and RecoverabilityRecoverabilityThe R in C/A/R: how well a team or service restores acceptable service after a failure. Recovery times and tested alternatives can supply evidence.) figures. Flow-log exports show where the network sent or blocked traffic. NovusLens reads these systems. It does not change them.

How a source becomes observations

1. The customer authors a mapping. A JSONJSONJavaScript Object Notation: a text format for data, using named fields, lists and values. Configuration files and service messages use it. file joins the source’s own vocabulary (ticket groups, Prometheus jobs, repositories, services) to cells and capabilitiesCapabilityWhat a team can provide or an agent can do. NovusLens records the claim and the evidence that supports it. the twin already holds. An unmapped item is counted and reported, never guessed onto a cell.
2. An acquirerAcquirerA program that reads a customer's operational records, calculates quantities from them and records the results in NovusLens. polls the source and computes quantities, for example lead time as the mean of resolved minus opened over resolved tickets only.
3. The acquirer writes the observations as last-write-winsLast-write-winsA rule for competing updates in which the update with the latest ordering stamp supplies the stored value. records under conway/… keys, with a refresh interval. If acquisition stops, readers stop counting the evidence as current after its refresh limit.
4. The correctorCorrectorThe NovusLens component that compares measurements with recorded statements and adds observations and differences to the log. compares the accounts. It compares the measured account with the asserted one, under a distributed lockDistributed lockA lock that coordinates programs running in separate processes or on separate machines, so only one holder is recognised at a time. whose fencing tokenFencing tokenA number that identifies a turn to update shared data. NovusLens rejects an earlier correction’s writes after a newer correction is applied. travels on every observed write. The materialiserMaterialiserThe component that reads recorded changes in order and updates the database. It records its place so it can continue after a restart. refuses a write from a stale holder. The difference between the two accounts becomes a findingFindingA difference in the records that needs a decision. It includes its sources and can describe a slow handoff, disputed fact or missing owner..

Open the diagramA customer source, its mapping, the acquirer, the mesh entries, the corrector and the materialiser.

Source types and combined acquisition

The connector cookbook describes five source types. Tickets (ServiceNow, Jira) give measured edge lead times. Metrics (Prometheus) supply the current numeric readings that the organisation already exports. The customer’s scoring rules turn those readings into C/A/R scores. Continuous integrationContinuous integrationAutomated checks run when code changes, usually including building the code and running tests. (CI, GitHub workflow runs) computes quantities from raw runs. Incidents (PagerDuty) measure recovery and nothing else, so on their own they refuse most cells. Network flows (Hubble or VPCVPCVirtual private cloud: a private network defined inside a cloud provider's infrastructure. Flow Logs exports) are the fifth kind. The composite acquisition command combines several sources under one calibrationCalibrationThe customer's own rule that turns raw figures, such as a gauge, a workflow history or an incident log, into a C/A/R score. A score moves when the calibration moves, and the change is recorded.. Each score uses the source that measures that quantity.

The pages in this section

The command line

Everything above is driven by ./lens connectors <verb>. Every verb takes a required --org, with --host and --port (they default to NOVUSLENS_MESH_HTTP_ADDR and NOVUSLENS_MESH_HTTP_BASE, then 127.0.0.1 and 8400), after the verb. ./lens hands them to python -m conway_connectors, where they are the root options before the verb. The verbs are listed with each page that owns them.