Units, owners and dependencies, read as one structure.
In plain words
NovusLens keeps a model of your organisation. It lists the units doing the work, their day-to-day and accountable ownersAccountable 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 the other units they rely on. Every fact in it carries its source, so you can see how it is known.
For an executive, three things matter. First, a team has two kinds of owner: the person who runs it, and the person who answers for it. The model keeps them apart. Second, a dependencyDependencyA link where one unit needs something from another. A dependency is not a reporting line: it shows where work relies on something else. is not a reporting line, and the dependencies are where delay travels. Third, the product never names an individual in small groups. The detail below is for stewards and engineers, and the code-level material is gathered at the end under “Implementation detail”.
What a twin is
A 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. is NovusLens’s own up-to-date model of how your organisation is wired, built from the evidence it has collected. Each organisation has its own twin, holding its records and nobody else’s. The twin is only as current as its inputs. This page describes what the twin contains.
What it is
The organisation model is the set of things NovusLens knows about an organisation: its units, who owns them, how they depend on one another, and who is mapped to them. Each unit is a 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.. A cell is a box on the mapMapThe view of teams, services and their dependencies for the selected part of the organisation. Details appear beside the map. that stands for a team, a service, a supplier or an AI agent. It is a unit you can inspect. It is not necessarily a department or a person.
Every fact in the model carries a source and an evidence rungRungOne of three levels of support for a recorded value: told, shown or measured. The level appears beside the value. (see the evidence ladder). A claim someone told the product in an interview sits beside a claim from an org chart export, and beside a measurement from telemetryTelemetryMeasurements and activity records sent by a running system, such as ticket timings, network traffic or workflow results.. The model keeps them apart. Where they disagree, the difference is raised as a finding rather than settled by the product.
An example
The GuideGuideThe help pages inside NovusLens. They explain the pages, input formats and tasks in the version you use. They are product instructions, not evidence about the organisation.’s illustration of a BufferedBufferedA handoff that takes more than one day and up to four days. It adds 1 point to the dependency-chain index. link is a bookings desk posting requests into a queue that Customs clears in two days. The two-day handoffHandoffWork or information passed from one team or service to another. Its measured or stated completion time determines the dependency class. makes the link Buffered. Customs waits five days for Legal’s approval before filing, so that link is RigidRigidA handoff that takes more than four days. It adds 3 points to the dependency-chain index.. A small org chart in the Guide’s input format shows the same structure before any flow is known. It lists operations as a top-level unit, bookings and customs as children with heads recorded, and freightsoft as an external vendor. The chart declares the boxes. The dependencies come later, from the interview or from telemetry.
How it works
Two kinds of unit, plus a note on the boundary. A unit is either part of the organisational layer (a team or business unit) or part of the implementation layer (a service or system). AI agents are units of their own. Whether a unit sits outside the organisation, as a vendor or partner does, is recorded separately. If nobody has said, the view shows a question. It never assumes an answer.
An ownership hierarchy. Units nest: a team contains its services. The model calculates couplingCouplingA link where one team or service depends on another. Its Loose, Buffered or Rigid class describes the time needed for a handoff. and 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. (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.) for each unit and the units it contains. See the three measures.
Business areas, recorded in the domain taxonomyDomain taxonomyThe list of business areas, their owners and the teams or services that do the work in each area.. A domain is a business area, described by what the work is, not by who owns it. A domain names an accountable owner and the units that serve it. One domain can span several units, and one unit can serve several domains. Where the business areas and team structure disagree, the map shows the disagreement as a misalignment. There are three kinds: a domain spread across several teams, a team that serves several domains, and a declared domain that no unit owns.
Dependencies and handoffs. A dependency says that one unit relies on another for a named capability. Each dependency has a handoff class, read from the measured lead timeLead timeThe elapsed time between starting a request or handoff and completing it.: one day or less is LooseLooseA handoff that takes about one day or less. It adds 0.5 points to the dependency-chain index., up to four days is Buffered, and longer is Rigid. A handoff with no known class is Unknown. An Unknown handoff has no weight in the critical path length (CPLCPLCritical path length. The total coordination weight of the longest chain of dependencies in the model. NovusLens reports it as index points, not elapsed time.). The CPL weights (0.5, 1 and 3 for Loose, Buffered and Rigid) are a fixed index for ranking coupling cost. They are not hours, and the lead time is kept beside the class so a reader can see the raw figure.
A dependency is not a reporting line. The hierarchy shows which units contain others. The dependency lines show where work relies on something else.
Two owners. The operational ownerOperational ownerThe person who runs a team or service day to day. This is not automatically the accountable owner, and NovusLens records the two separately. runs the unit day to day, as told. The accountable owner answers for it. The model does not treat them as the same person. An answer about the operational owner does not satisfy the accountability question. If no accountable owner is recorded, the view shows a gap in the record.
People and the privacy floorPrivacy floorThe rule that a unit with fewer than five mapped people is shown as a small team, never as a number. The key-person finding says fewer than five and never says who.. The people export maps individuals to teams, and teams to units. Employee ids and email addresses are scrambled irreversibly on the way in. The key-person check is the only use of this mapping that reaches 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.. It raises a finding for a unit on the measured critical pathCritical pathThe dependency chain with the greatest total coordination weight in the map. It identifies a structural constraint. It does not state elapsed time. that has one to four people mapped to it. The key-person check skips units with no mapped people. The privacy floor is five: below five people, no count is shown. The finding says “fewer than five”, never names a person, and never gives a count below the floor. See the privacy floor.
External units and suppliers. A supplier is a unit marked external. Dependencies can cross the line between the organisation and its suppliers. A supplier with a service level agreement sits on three levels of evidence: no records, a declared agreement, then a boundary measurementBoundary 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. from the organisation’s own side. The governance check compares a declared availability target with the measured figure for any external unit. A declared target set beside a measured figure that does not meet it is raised as a finding that names both sides.
Interfaces
| Input | Purpose | Command or page |
|---|---|---|
| Org chart export | Units, parents, heads, responsibility and granted authority. Declares boxes, not flow. | ./lens connectors orgchart |
| People export | Team and person mapping for the key-person check. | ./lens connectors people |
| Domain taxonomy | Business domainsDomainA business area defined by the work it does, such as purchasing or customs. It may involve several teams, and one team may serve several areas., their owners, and the cells that serve them. | ./lens connectors domain-taxonomy |
| Interview | Flow and dependencies, told by the organisation. | Capture pages in the web application |
Run the commands from the installation directory. ./lens connectors runs python -m conway_connectors in the running installation. Find the input formats in the Product Guide.
Invariants and limits
- A chart declares structure, never flow. Dependencies come from the interview or from telemetry.
- An omitted field in a later org chart is kept as it was. An omission is “not stated”, never a removal.
- A people export that is not marked complete can add or move people, but it never removes anyone.
- The domain taxonomy can only grow. A removed cell does not remove its mapping.
- A missing record is a question to investigate. It is not proof that a dependency does not exist.
- The key-person finding is a recorded fact about who is mapped to a cell. It is not evidence that a person did the work.
- Scope affects reading. A very small scopeScopeThe work, data, activity or access that a rule, statement or calculation covers. For access, it names the records an account can see. For team measures, “Own operations” covers the selected unit. “Including descendants” adds the units beneath it. reads less precisely, and that is the privacy floor working.
What to do next
Open a unit and read its owner fields and its source beside each one. For a Rigid dependency, ask both teams what they wait for. For a domain with no owning cell, ask the accountable owner whether the domain is real. Record any clarification through the supported import or capture path, so that it lands as a source the product can show.
Implementation detail
This section names the code-level identifiers behind the plain account above.
Cell kinds. In the meshMeshA set of connected Mycelium services that exchange updates and keep the NovusLens log. model, a cell has a kind: domain for a unit in the organisational layer, or infra for a unit in the implementation layer. Agent units are created with kind="agent". Whether a unit sits outside the organisation is a separate flag, is_external. It is True for a vendor or partner, False for an internal unit, and None when nobody has stated it.
Ownership hierarchy. A cell can have a parent_cell_id.
Domain taxonomy. A domain names an accountable_owner. The taxonomy is imported from a workshop page by domain_taxonomy.py, which writes a record for each link between a cell and a business area. The three misalignment findings are boundary-smeared-domain, boundary-overloaded-team and boundary-unowned-domain.
Owner fields. operational_owner is who runs the unit day to day, as told. accountable_owner is who answers for it.
People and the floor. Employee IDs and email addresses are replaced by hashesHashA fixed-length fingerprint calculated from content. Comparing fingerprints helps detect changes and match records. on the way in. A deployment-specific secret, called a saltSaltExtra data mixed into a value before its fingerprint is calculated. It makes matching or guessing the original value harder., makes those identifiers harder to guess. The module personnel.py expects a secret salt for each deployment, CONWAY_IDENTITY_SALT. Without it, a public development salt is used and a warning is written to standard error. The key-person check is in keyperson.py. It raises key-person-risk for a cell on the measured critical path with one to four mapped people. It skips cells with no mapped people. unowned-capability comes from a separate missing-ownership statement in interview capture. PRIVACY_FLOOR = 5 in keyperson.py, and the cell_headcount function in migrationMigrationAn ordered change to a database's tables or rules. Applied migration files are recorded so the same file is not run again. 0037_privacy_floor_five.sql returns no count below five. The finding sets mapped_person_count to nothing.
Suppliers. The governance check is control-gap-declared-control-unmet.
Where it is implemented
The vocabulary (cell kinds, handoff classes, provenanceProvenanceThe record of where a value came from, who stated it and when. Every value keeps this record. rungs, owner fields) is in apps/mesh/src/conway_mesh/model.py. The key-person check and its floor are in apps/graph/src/conway_graph/keyperson.py, with the database function in apps/graph/migrations/0037_privacy_floor_five.sql. The misalignment findings are in apps/graph/src/conway_graph/misalignment.py. The governance checks on external nodes are in apps/graph/src/conway_graph/governance.py. The identity saltIdentity saltA secret value added before employee identifiers are turned into fingerprints. Keep the same value so later imports can still match existing people. is in apps/connectors/src/conway_connectors/personnel.py. The key shapes are in apps/mesh/src/conway_mesh/keys.py.