Core terms
AI engineering combines developer tools, local agents, model services, source control, and security policy. The same word can mean different things in vendor dashboards and internal reports. These definitions describe how MainLayer uses each term so engineering, security, finance, privacy, and procurement teams can review the same system with a shared vocabulary.
| Term | Definition |
|---|---|
| AI engineering control plane | A management layer that observes, governs, protects, and measures AI-assisted software development across tools. It joins endpoint events, repository inventory, pull requests, policy, cost, and security findings without becoming the model gateway itself. A control plane should state which capabilities are enforced, observed, partial, or unsupported. |
| Adapter | A provider-specific integration that discovers an installed AI coding tool, reports its capabilities, installs or reconciles owned hooks, translates provider events into a common telemetry contract, and reports health. Adapters preserve differences between tools instead of pretending every provider exposes the same session, prompt, token, MCP, or enforcement surface. |
| AI-assisted pull request | A pull request with evidence linking at least one AI coding session to its branch, commits, files, or change fingerprints. The label indicates observable assistance, not full AI authorship, correctness, or quality. MainLayer keeps the evidence type and confidence beside the result so readers can judge its strength. |
| Attribution | The process of linking AI session evidence to a software work item such as a pull request. MainLayer uses repository identity, branch or commit links, time windows, and privacy-safe file or hunk fingerprints. Attribution is an estimate with stated limits, not a claim about intellectual authorship or individual productivity. |
| Audit chain | An ordered audit history in which each row includes a cryptographic hash connected to the previous row. Recomputing the chain can reveal alteration or deletion within the retained sequence. The chain protects record integrity, but it does not turn an unsupported control into an enforced one or prove external events occurred. |
| Capability matrix | A provider-by-feature statement of what an adapter can do. Values such as supported, partial, detect-only, and unsupported distinguish reliable enforcement from observation or inference. Teams should consult the matrix before applying a block or redaction policy because prompt, tool, MCP, token, and session capabilities vary by product. |
| Content allowed | A privacy level in which an organization deliberately permits specified content-bearing telemetry under its controls. It is not the default. Enabling it should require a documented purpose, repository scope, access rules, retention decision, and review. A content-allowed setting does not override provider terms or data classification policy. |
| Contribution estimate | The percentage of pull-request added lines associated with matching generated-change evidence. In v1, MainLayer sums matching generated additions per file, caps them at that file's additions, and divides total matched lines by all additions. It is null when there are no added lines and carries a separate confidence tier. |
| Data loss prevention (DLP) | Controls that detect sensitive patterns in supported prompts or tool inputs and apply an action such as observe, warn, redact, or block. MainLayer scans on the developer machine and sends pattern identifiers, counts, surfaces, and salted fingerprints rather than matched text. Actual prevention depends on the provider's hook capabilities. |
| DefinedTerm | A Schema.org structured-data type for a named concept and its description. Glossaries can publish each entry as a DefinedTerm inside a DefinedTermSet so search engines and other machines can interpret the page's vocabulary. Structured data describes visible content and should not introduce claims absent from the page. |
| Detect-only | A capability status meaning the integration can identify a condition or event but cannot reliably control it. For example, an adapter might see that a prompt was submitted without having a supported way to stop or rewrite it. Policies must report detect-only outcomes instead of presenting a configured block as successful enforcement. |
| Enforcement status | The observed result of applying a desired policy action. MainLayer distinguishes enforced, warn-only, observe-only, and unsupported outcomes. This field is separate from the requested action because provider interfaces differ and hooks may fail. Honest status lets security teams identify gaps without assuming every policy behaved identically across tools. |
| Event envelope | The common structure around a telemetry event, including event identifier, schema version, time, domain, type, provider, model when known, session identifier, repository state, privacy level, and a typed payload. The server stamps tenant, user, and device identity from the authenticated device rather than trusting client-supplied values. |
| Exception | A documented, scoped departure from a policy for a user, team, or repository. An exception records the policy, reason, approver, scope, and optional expiry. When it matches, the outcome may become allow with exception-used evidence. Exceptions should be narrow, reviewable, time limited where practical, and visible in audit history. |
| Fingerprint | A one-way digest used to compare an item without sending its original value. MainLayer fingerprints normalized repository remotes, file identities, configurations, installations, and selected findings. Equality can establish that two observed items match, but a fingerprint does not reveal content and should still be handled as organization-scoped metadata. |
| Hunk fingerprint | A one-way identifier for a contiguous change region in a diff. Matching endpoint and pull-request hunk fingerprints can provide more precise survival evidence than matching only a file. MainLayer v1 does not claim hunk-level pull-request matching because its pull-request file record does not yet store the required patch fingerprints. |
| Managed repository | A repository whose normalized remote fingerprint matches the organization's connected repository inventory. Managed status lets session and pull-request evidence join to the same repository record. A repository can be unmanaged, local-only, or unknown when no match exists, no remote exists, or resolution fails. Status does not expose source contents. |
| MCP | Model Context Protocol, a standard through which an AI application can discover and call tools or resources offered by a server. In engineering workflows, an MCP server may reach databases, ticket systems, browsers, files, or internal APIs. Its permissions, package source, configuration, and tool descriptions therefore belong in the approval process. |
| MCP proxy | An organization-enabled local wrapper for supported stdio MCP servers. It can observe calls and apply catalog or policy decisions before forwarding them. MainLayer does not rewrite HTTP, SSE, or streamable-HTTP servers through this proxy, so those connections remain observe-only unless another provider or network control governs them. |
| Metadata only | The default privacy mode in which the service receives operational times, event types, provider and model identifiers, counts, repository state, labels, and one-way fingerprints. It excludes raw prompts, source code, file contents, diffs, credentials, keyboard or mouse activity, screens, and terminal history. Server validation rejects content-bearing fields in this mode. |
| Monitored developer | A person with an active MainLayer seat assignment whose enrolled endpoint can produce AI engineering telemetry. Monitored developers are the subscription quantity. Administrative, management, security, finance, and viewer access does not consume a monitored seat by itself. Activity reports should not confuse having a seat with being active during a selected window. |
| Policy bundle | A signed, versioned document delivered to an enrolled device. It contains applicable policies, exceptions, team memberships, approved MCP fingerprints, budget state, organization identity, and policy contact. The agent verifies the signature and caches the last good bundle, allowing local decisions without sending prompt or tool content to the server. |
| Pricing coverage | The share of observed tokens associated with a known model price. A cost estimate with low coverage omits meaningful usage and should not be treated as a complete total. MainLayer leaves unknown-price costs null rather than guessing, and organization-specific price overrides can replace public defaults when a contract uses different rates. |
| Provider | An AI coding product or integration source such as Claude Code, Cursor, GitHub Copilot, Codex CLI, Gemini CLI, Antigravity, Amp, OMP, or OpenCode. Provider identity describes the tool surface that produced an event. The underlying model may come from another company and is recorded separately when the provider exposes it. |
| Repository state | A session classification of managed, unmanaged, local-only, or unknown. It comes from resolving the working directory, reading Git remotes, normalizing them, and comparing privacy-safe fingerprints with the managed inventory. Repository state helps scope policy and reporting while avoiding raw remote credentials and source collection. |
| Sanitized | A privacy level for data that has been transformed to remove or mask sensitive content before transmission. Sanitization is stronger than simply labeling content and must be supported by the exact provider surface. If a hook cannot rewrite a prompt or tool input, the system should warn or block rather than falsely report successful sanitization. |
| Seat | The billing and access assignment for one monitored developer. In MainLayer, active seat rows determine required subscription quantity, with a minimum billable quantity where the billing contract applies. Seats are independent of portal roles. Releasing a seat ends the active assignment but should not erase historical aggregate or audit records. |
| Session | A bounded period of AI-assisted development associated with a provider session reference, developer, device, repository context, and events. A session becomes active on AI activity, idle after the configured quiet period, and ended through a provider hook or timeout. MainLayer does not infer activity from keyboard, mouse, screen, or terminal-history monitoring. |
| Shadow AI | An AI tool, account, model, extension, MCP server, plugin, or skill used outside the organization's approved inventory or controls. A finding indicates a management gap, not malicious intent. MainLayer discovers a defined catalog of unmanaged local tools and reports privacy-safe installation facts; it does not inspect browsing or terminal history. |
| True-up | A billing adjustment that increases purchased subscription quantity when active monitored seat assignments exceed the current quantity and automatic synchronization is enabled. MainLayer never reduces seats automatically. Organizations review and make downward changes through the billing portal, which prevents surprise access loss while making regular seat hygiene necessary. |
| Tool-risk finding | A record that an MCP server, skill, extension, package, or plugin matched a licensed advisory source or local heuristic. Findings may identify malware, vulnerabilities, impersonation, deprecation, unpinned execution, credential access, hidden instructions, or exfiltration patterns. The endpoint sends labels and hashes, not scanned skill, prompt, or tool-description content. |
Use definitions with their evidence
A shared vocabulary is useful only when reports preserve the distinctions behind it. Keep desired action separate from enforcement status, seat assignment separate from recent activity, assistance separate from contribution, and an estimate separate from an invoice. These boundaries make cross-tool reporting comparable without erasing the limitations of each provider or the privacy choices of the organization.