Portfolio Monitoring

Portfolio Monitoring is the recurring program for companies you enroll under a legal organization: an initial audit of every selected file, then a quarterly audit every three months that re-reviews only the code that changed, and a monthly pulse in between.

It is distinct from a one-off diligence audit you start from Create New Audit. Monitoring clones through a connected Git account so the program does not wait on someone running the CLI.

What runs, and in what order#

Portfolio Monitoring runs three things for each enrolled company, in this order:

The initial audit is the company's first audit, and the only one a person starts: the Repo Owner marks it ready and one of the fund's administrators presses Start. It has no date, and nothing starts it on its own. The first quarterly audit is due three months after the day the initial audit was started, and every later one a quarter after the previous one. Quarterly audits run on their own; no quarterly audit starts while the initial audit is still open.

Both kinds are full audits: quality, security analysis and finding validation all run, so every audit of the program has a complete result for every selected file.

The initial audit#

The initial audit is the company's first audit in the program. It reviews every file the import selects in each approved repository, the same way as a full audit you start yourself, and it becomes the starting point every quarterly audit builds on.

• A fund administrator starts it. CodeDD prepares the audit when the company is enrolled. The Repo Owner imports the repositories, checks the file selection and marks the audit ready; then one of the fund's administrators presses Start in Portfolio Admin or on the audit page. Only the fund's administrators start it, see what it costs in lines of code and agree to lines above the included cap. Start on the invitation, the dashboard or the CLI is refused for this audit.
• The file selection carries forward. Files deselected here stay out of later quarterly audits, and files added here that the import leaves out, such as tests, stay in, until you change them with Scope for later audits. A folder you deselect on the scope screen keeps the files added to it later out too: saving the selection saves that as a folder rule, without asking. When you save a change to a file type or the minimum lines filter, or bring a folder back, the Files added later dialog offers to apply it to files added in later audits too. The fund administrator sees the rules saved that way in Portfolio Admin before pressing Start. See Scope rules.
• The same for companies moved from the earlier program. A company that already had completed audits in the earlier program, but no full audit, gets its initial audit the same way: when a fund administrator presses Start, never on a date.
• Included up to 5 million lines. Above that, Start shows the extra lines and what is left of the annual allowance, and the audit starts only once a fund administrator agrees to take them from it. If the lines measured before the analysis grow past what was agreed, the audit waits for a new confirmation. Files that no audit ever reviewed and that you bring back later with Scope for later audits count against the same included lines before they draw on the allowance.
• Pilots included. A 3-month pilot gets its initial audit under the same cap.
• When it cannot run. Nothing retries the initial audit on a date. One that stops for a cause that can be fixed (Git access, the plan check) waits until a fund administrator presses Start again, and the first quarterly audit then counts from that Start. One that failed for good closes three weeks later, and a prepared one nobody marks ready closes after two weeks; the next Start opens a fresh attempt. One held for confirmation of the lines above 5 million does not lapse: it waits, with a weekly reminder, until a fund administrator confirms, and no quarterly audit runs meanwhile.

For a company moved from the earlier program, a completed full audit in CodeDD, for example the earlier program's yearly Full Audit or one from due diligence, counts as its initial audit and the program starts with a quarterly audit. That quarterly audit reuses the earlier audit's results for files that have not changed since, and reviews the rest. A newly enrolled company always gets its own initial audit, even when a full audit of some of its repositories ran before enrollment.

Quarterly audits#

A quarterly audit is the recurring audit of an enrolled company, due every three months after the initial audit. It re-reviews only the files whose code changed since the AI last reviewed them and reuses the last result of every other selected file.

• Compared with what was reviewed, not with a date. CodeDD records, for every file, which version of its content the AI reviewed. The next audit compares the file in Git today with that version. A late or skipped quarter therefore misses nothing: a file changed at any time since its review is reviewed again.
• Unchanged files keep their last result, however old. A file untouched for two years still carries the result of the audit that reviewed it, and CodeDD records which audit that was and when it reviewed the file.
• No lines used. Quarterly audits do not draw on the lines of code allowance, including the lines they re-review. Each audit records how many lines it re-reviewed. The one exception is a file you bring back with Scope for later audits that no audit ever reviewed: it counts against the included lines first, then the annual allowance (see Lines of code for files you bring back).
• Runs unattended. The scope is the approved repository list and the file selection the earlier audits established, and nobody is asked to confirm it. The audit's own scope screen is read-only and shows the selection carried forward. The one exception is the first quarterly audit of a repository added later (see Which files a quarterly audit covers). To change what later audits cover, use Scope for later audits in Portfolio Admin or on the company's dashboard. A change applies from the next quarterly audit (see Changing the scope for later quarters).

Every quarterly audit records, per repository, how many files were reviewed because they are new or changed, and how many results were reused because the file is unchanged, changed only in comments or formatting, or renamed.

What counts as a change#

A file counts as changed in a quarterly audit when its code differs from the version the AI last reviewed. Edits that leave the code itself the same are not changes, so the earlier review still applies.

Not a change:

• edits to comments and docstrings only;
• formatting only: spacing, line wrapping and blank lines, in languages where whitespace has no meaning;
• a file moved or renamed with its code unchanged.

Always a change:

• any edit to the code itself;
• indentation in indentation-sensitive languages such as Python, YAML, Makefiles, F# and Haskell, and line breaks in line-based languages such as shell scripts, Ruby and INI files;
• comments that steer tools or the compiler, such as # nosec, // NOSONAR, # noqa, eslint-disable, pragmas and preprocessor lines, because they change what scanners report;
• any file whose language CodeDD cannot read with certainty, binary or very large files, and files whose earlier version Git no longer has.

When in doubt the file is reviewed again. After a comment-only edit the reused result still refers to the reviewed version, so a series of small comment edits is always measured against the code the AI actually saw.

Which files a quarterly audit covers#

A quarterly audit covers the files of the approved repositories at the commit it clones, with the selection the earlier audits established:

• Files already in scope keep their selection. A file selected before stays selected, including one you added that the import leaves out, such as a test; a file you deselected stays deselected. Both stay that way until you change them with Scope for later audits.
• Choices are stored per file for the files that exist. Ticking a folder, a File Extensions chip or a Minimum Lines of Code filter selects or deselects the files it covers at that moment, and CodeDD stores the outcome for each of those files. That choice does not cover files added later. Scope rules decide those.
• New files follow your scope rules, then the normal import selection. A file that did not exist before is checked against your scope rules first. When no rule decides it, it is selected only if the import would select it in a new audit, so new tests, vendored and generated files stay out, also in a folder you selected as a whole. Likewise, a new file the import selects is in scope even in a folder, or with an extension, you deselected, unless a rule says otherwise.
• Removed files drop out. A file deleted from the repository is no longer part of the audit.
• Renamed files keep their result. A moved or renamed file reuses the earlier result unless its code changed too. It keeps its selection as well, unless it moves under a different scope rule, for example into a folder a rule excludes.
• A repository added later is reviewed in full. When you add a repository to the approved list, its first quarterly audit reviews every selected file in it. Your scope rules for every repository apply to its files from the start. It still uses no lines of the allowance. Its selection starts as the import's with your scope rules applied, and the scope screen of that first quarterly audit stays editable until the audit starts: fund administrators, the company's portfolio initiators and members, and the people who imported the repository can change its file selection there. Everyone else sees it read-only, and once the audit has started the selection is final. Its scope for later audits can be changed once that audit has finished.
• Renamed repositories keep their history. A repository renamed or moved on the same Git provider is still compared with its earlier reviews.

Scope rules#

A scope rule is a standing instruction about files that do not exist yet. It says that new files in a folder, of a file type, matching a pattern or below a size are kept out of the audits, or brought in. The choices you make on the scope screen cover the files in scope today. Rules cover the files added later.

Rules apply to Portfolio Monitoring audits. A one-off audit you start yourself does not use them.

What a rule matches#

Every rule has one kind, applies to one repository or to every repository of the company, and either excludes or includes the files it matches.

• Exclude or include. An exclude rule keeps the new files it matches out of the audits. An include rule brings them in, also where the import would leave them out, such as tests. A minimum lines rule can only exclude.
• Limits. A company holds up to 200 rules. A pattern has up to 512 characters and 8 wildcards, and needs a fixed part, such as **/migrations/** or **/*.sql: a pattern of wildcards alone, which would cover the whole repository, is refused. A repository, or the company as a whole, holds one minimum lines rule.

What rules decide#

• New files. A rule decides a file that no earlier audit knows. Every file of a repository's first audit is new, so a rule for every repository also shapes the selection of a repository added later.
• Files moved under another rule. A moved or renamed file keeps its selection. When its new path is governed by a different rule than its old path, for example it moves into an excluded folder, that rule decides.
• Earlier choices stand. A file that earlier audits already know keeps the selection it has, whatever a rule says. A file you selected or deselected by hand on the scope screen is left to your choice only when that choice differs from both what the import would pick and what the rules would give, and only when CodeDD builds or rebuilds the audit's plan after your change. A hand choice that matches what the import would pick, or what the rules would give, is decided by the rules, like any new file.
• Hidden files and files with no code stay out. An include rule never selects a hidden file such as .env, a file in a hidden folder such as .github, or a file with no lines of code or documentation. An include rule for a hidden folder is refused.
• Minimum lines is judged again every quarter. A new file below the minimum is left out of that audit without a lasting decision. The next quarterly audit checks it against the minimum again, so a small file that grows past it is reviewed. The other rules record their decision for the file, so a new file they keep out stays out.

Which rule wins#

When more than one rule matches a new file, the most specific one decides. CodeDD compares them in this order, and the first difference settles it:

1. A rule for one repository beats a rule for every repository.
2. A folder beats a pattern, and a pattern beats a file type.
3. A deeper folder beats a shallower one. Between patterns, the one with more literal characters, those that are not wildcards, wins. Between file types, the longer one wins, so .d.ts beats .ts.
4. When two rules are equally specific and disagree, exclude wins.

A minimum lines rule applies last, to a file that is selected at that point.

Where to manage rules, and who can#

• On the scope screen of the initial audit. A folder you deselect as a whole becomes a folder rule when you save (see Folders you leave out). For a File Extensions chip, the Minimum Lines of Code filter or a folder you bring in, the Files added later dialog asks whether to apply your changes to files added in later audits too. Each change is a line you can tick, such as "Exclude new .sql files". A line that excludes files starts ticked. A line that includes files, such as "Include new files in vendor/acme/", starts unticked. An include rule also brings in new tests, vendored and generated files that match, so tick it only if you want that. Leave a line unticked to keep that change to today's files. A file type or minimum lines line can apply to this repository or to every repository of the company. The Rules for later audits list on the summary tab shows the rules that apply to the repository and removes one until the audit starts.
• In Portfolio Admin. Open the company, then Code & Repositories. You add and remove rules there between audits, once the initial audit has completed and while no audit is prepared or running; while one is, add the rule after it has finished. Before the initial audit starts, Portfolio Admin only lists the rules (see the next point), and you change them on the scope screen of the initial audit. Each repository in the table of repositories in scope shows how many rules were set for that repository; its Add rule button or rule count opens the list, where you add and remove them. The count does not include the rules for every repository: Company rules manages those. Rules of a repository no longer in scope are listed under that table, where you can open and remove them. They apply again if the repository returns. The list shows who set each rule, how many files it decided in the latest audit, and flags a folder rule whose folder was gone at the latest audit. A new rule that overlaps another names it, and a rule with the same target as an existing one asks before it replaces that one. Scope for later audits and Scope history are there too.
• Before the initial audit starts. Portfolio Admin shows the saved rules read-only, so the fund administrator sees them before pressing Start, including those the Repo Owner and the company's team saved on the scope screen. Under Code & Repositories, a note such as "3 scope rules apply to later audits" says how many there are and whether they apply to every repository or to one. View rules opens the full list, grouped by repository. Nobody adds or removes a rule there. Edit this audit's files on a repository opens its scope screen. The note does not appear while no rule is saved. Once the audit has started it goes away, and the rules return to the table of repositories in scope when the audit has completed.
• When a change counts. A new rule applies from the next quarterly audit, or from the one after when CodeDD has already worked out what changed for the audit that is about to start. Removing a rule stops it deciding files added after that, and the files it already kept out stay out. Use Scope for later audits for files already in scope, or to bring back what a removed rule kept out. A folder you bring back there also brings back what an exclude rule kept out in an earlier audit, but a file marked "Kept out by your scope rules", typically one below your minimum lines, only when you tick the file itself.
• Who can manage rules. Between audits, rules are added and removed in Portfolio Admin, which only fund administrators can open. On the scope screen of the initial audit, fund administrators, the company's portfolio initiators and the company's team, the Repo Owner included, add and remove rules until the audit starts, and the fund administrator sees them before pressing Start.

Folders you leave out#

• They stay out. A folder you deselect as a whole on the scope screen, in the tree, with the search or with a suggestion of the scope review guide, becomes a folder rule when you save the selection, without asking: files added to it later stay out of later audits too. Selecting the folder again removes its rule. Scope for later audits does the same when its change applies.
• They say who left them out. A folder a rule governs, and every folder inside it, carries a chip such as "Left out by Anna Meyer · Nov 3, 2026". Its tooltip names the audit and what happens to files added later. The chip also shows on the read-only scope screens of later audits and in the editor of Scope for later audits. A single file you deselect by hand has no such chip: who chose it is not recorded.

Changing the scope for later quarters#

Scope for later audits changes what later quarterly audits cover for files that are already in scope: it brings a folder or a few files back into the audits, or takes them out. You save a change now and it starts with a later quarterly audit. It never changes the quarterly audit that is open now. Scope rules decide the files added later, and a change decides the files that exist today. Audits that have finished keep their results as they were.

Who can change it and when it applies#

• Who. Fund administrators and the company's portfolio initiators. The Repo Owner and the company's team cannot. A portfolio initiator who is not a fund administrator opens Scope for later audits from the dashboard of a company they initiated.
• Where. In Portfolio Admin, open the company, then Code & Repositories. Between audits the table of repositories in scope has a Next quarter column with an Edit later scope button for each repository, and a chip such as "1 change waiting". While a quarterly audit is prepared or running, Scope for later audits is in the head of the section and asks which repository, and Edit this audit's files on a repository opens the scope screen of the audit that is open now. The company's dashboard has a Scope for later audits button for the same people, and the read-only scope screen of a quarterly audit links to Scope for later audits for them. Both open a page that asks which repository and also lists the changes waiting and the scope history.
• When it opens. Nothing shows until the company's initial audit has finished. After that a repository opens once an audit of the program has finished for it, the initial audit counting as one, and shows "Available after its first audit" until then. A repository imported into the quarterly audit that is open now is listed too, before it joins the approved list, and shows the same until that audit has finished; while the open audit holds it, Edit this audit's files opens that audit's scope screen. A repository added later, and every repository of a company whose earlier full audit counted as its initial audit (see The initial audit), opens once its first quarterly audit has finished. A company moved from the earlier program that gets an initial audit of its own opens its repositories once that audit has finished. A company with no later quarterly audit scheduled, a one-off or a completed program, shows "No later audit scheduled" and cannot change its scope. A paused schedule accepts a change, which applies when monitoring resumes.
• When it applies. From the next quarterly audit that has not yet worked out what changed for the repository. An audit that already has is not changed, and the change starts with the one after. The editor and the list of waiting changes name it by its date, as in "the quarterly audit due Jan 22, 2027". The date is a forecast: it moves when the next audit's date moves.
• Limits. A change names up to 10,000 files and 500 folders. When the editor says "Too many separate changes to save at once", change whole folders or save in several steps; changes to one repository stack. Up to 50 changes, and 50,000 files and folders for each repository, can wait at a time. A repository with more than 200,000 files cannot be edited here.

What the editor shows and what a folder covers#

• What you see. The files of the repository as of its last finished audit, with the folder checkboxes, the File Extensions chips and the Minimum Lines of Code filter of the scope screen. A file with a waiting change is marked "Added from next quarter" or "Removed from next quarter", a file that no audit ever reviewed is marked "Never reviewed", and a file your scope rules keep out without a lasting decision, typically one below your minimum lines, is marked "Kept out by your scope rules". A file an exclude rule kept out in an earlier audit has no such mark: like a file you deselected, it comes back with its folder. A file your scope rules will bring in that no audit has decided yet, for example one that passes a minimum you lowered, shows as selected and uses no lines. Review changes opens a summary with the numbers, an optional note and Submit change.
• Folders and files. A folder you tick or untick as a whole is saved as one folder when that leaves all its files selected or all of them unselected, and it then also covers files added to the folder since the audit you see. Otherwise CodeDD saves the individual files.
• Files your scope rules keep out. Ticking the folder of a file marked "Kept out by your scope rules" does not bring it in. Tick the file itself to bring it in, unless the import leaves it out too, as it does tests, vendored and generated code. Select All and the File Extensions chips tick such files as well. A file brought in this way was never reviewed, so it counts against lines of code.
• Files added later. A change to a folder also covers files added to it before the audit that applies the change. A folder you take out keeps them out, even where an include rule would bring them in. In a folder you bring back, your scope rules decide them: a file one of your exclude rules or your minimum lines rule keeps out stays out, a file an include rule selects comes in, and a file no rule decides is reviewed only if the import selects it, so not a test, vendored or generated file. Files added since the last audit use no lines of code. When a change applies, a folder it takes out becomes a folder rule, set in your name, so files added to it after that stay out too; a folder it brings back loses the exclude rules of that folder and of the folders inside it, so files added there follow the normal import selection again.

Which files are reviewed and which are reused#

A change reviews nothing by itself. The quarterly audit that applies it sorts each file it brings back by what is known about it:

• Never reviewed. A file that no audit ever reviewed, for example one in a folder deselected before the initial audit or one a minimum lines rule kept out that you tick on its own, is reviewed as a new file. These files count against lines of code (see Lines of code for files you bring back).
• Reviewed before. A file that an earlier audit reviewed and that you took out keeps that review. Brought back, its result is reused when its code has not changed since, comment and formatting edits not counting (see What counts as a change), and it is reviewed as a changed file otherwise. Reused files use no lines.
• Taken out. A file you take out leaves the quarterly audits from the one that applies the change. Earlier audits keep their results.
• Cannot be brought back. A hidden file, such as .env or a file in .github, and a file with no lines of code or documentation.
• The summary. Before you submit, it shows for each repository how many files were never reviewed, how many were reviewed before and how many are taken out. Files reviewed before are reused if their code has not changed. It also says how many files in the selected folders your scope rules keep out; they are not reviewed. To bring one in anyway, tick the file itself.

Lines of code for files you bring back#

Reviewing a file for the first time is the same work as in the initial audit, so the files that a change brings back and that no audit ever reviewed count against lines of code. Nothing else does: files reviewed before, files added since the last audit and files you take out use no lines, like any quarterly change.

• What is counted. The lines of code and documentation of each never-reviewed file the change brings back. They are counted when you submit the change, from the audit the editor shows, and they stay as counted when the audit runs.
• Included lines first. They count against the company's included 5 million lines. What the initial audit used is not available again, and each saved change takes what it needs from the rest. Only the part above that draws on the fund's annual allowance. For a company moved from the earlier program whose earlier full audit has no recorded size, CodeDD counts all the included lines as used, so these lines come from the allowance.
• A fund administrator agrees to any use of the allowance. The summary shows the lines, how many the included lines cover and how many come from the allowance, with a box "I agree to take N lines from the allowance". Submit change stays disabled until a fund administrator ticks it. A portfolio initiator who is not a fund administrator sees how many lines the change would review for the first time. When it needs the allowance, they are told that a fund administrator has to make the change, and they can cancel and bring back fewer files that were never reviewed. When the allowance is too small, the summary says so and offers Contact us.
• Held, not refunded. The lines a change takes from the allowance are held as soon as it is saved, and its share of the included lines is spoken for. Withdrawing the change before an audit picks it up releases both. Once an audit has applied it, nothing is refunded, also when some of its files were deleted in the meantime. Lines released after a contract year has renewed go back to the year they were taken from, so the allowance of the current year does not change.
• No double counting. While an earlier change that holds lines is still waiting and no audit has picked it up, you cannot save another change that covers any of the same files, because the lines would be held twice. Withdraw the earlier change first, then save the new one.

Withdrawing a change and the history#

• Waiting changes. Under the table of repositories in Code & Repositories, and on the Scope for later audits page that opens from the company's dashboard, "Changes waiting for the next quarterly audit" lists each change with the date it was saved, its files and folders, its repositories, the audit it applies from, who saved it and its note.
• Withdraw. Withdraw works until a quarterly audit has picked the change up. It asks "Withdraw this change? Nothing in your audits changes." and releases the lines held for it. Once an audit has picked it up, the list says "A quarterly audit has picked this up. It can no longer be withdrawn.", also when that audit failed or did not finish, because it may have used the change. To undo it, save an opposite change for the audit after it.
• Newer wins. When two changes cover the same file, the newer change decides. Within one change, a file beats its folder and a deeper folder beats a shallower one.
• Scope history. Scope history, in the head of the repositories in scope and on the Scope for later audits page, lists the rule and change events of the company, newest first, with the date, who did it (You, A colleague or CodeDD) and a link to the audit that applied a change. Fund administrators also see when a fund administrator confirmed using the allowance. It shows no line figures and no notes.
• Emails. When a change is saved, the fund's other administrators get an email that names the audit it applies from and says it can be withdrawn until then. It carries no line figures. The email about a finished quarterly audit adds "Scope changes applied: N." when the audit applied changes.
• Archived companies. Archiving a company withdraws its waiting changes that no audit has picked up, and releases their lines.

Reused results and security findings#

A reused result is the AI review of an unchanged file carried into the new audit. It is copied into the new audit, so scores, dashboards, chat answers and reports read it like any other result, and older audits stay exactly as they were.

• Security findings move with the file. Findings of a reused file are carried over with their validation, so the quarterly audit shows the same verdicts without validating them again.
• Verdicts that rest on other code are checked again when that code changed. When the validator judges a finding invalid or mitigated, it records the files it read and the searches it ran for that verdict. A carried verdict is validated again only when the code of one of those files changed (comment and formatting edits do not count) or one of its searches now matches a changed source file. Configuration and build files that CodeDD does not import as code, such as Dockerfile, docker-compose.yml, nginx.conf, package.json and __init__.py, are not searched again, and a verdict that read one of them is validated again in every quarterly audit. Verdicts recorded before CodeDD kept this record, or with an incomplete record, follow the earlier rule: they are validated again when the file they name changed at all or, when they name none, when any selected file of the repository changed.
• Your triage carries forward with a reused result. A finding someone marked as not an issue, resolved or commented on keeps that decision in every later audit that reuses its file's result, and the AI never validates it again: a person's judgement is not reopened by an automatic re-check. When the file is reviewed again, because its code changed or because CodeDD could not reuse the earlier result in that audit, its findings start without triage. If the earlier result could not be reused for the whole repository, the next quarterly audit picks the earlier triage up again; if it could not be reused for a single file, that file's triage does not come back. That includes a triaged finding that was never validated, for example because it was beyond the number of findings one audit validates: a quarterly audit that reuses its result leaves it out of the AI validation as well. Triage set on an older audit after a newer one has completed is not added to the newer one.
• Comment-only edits move the line numbers. Findings of a file whose comments changed point at the lines where the code now is.
• Measurements are always fresh. Lines of code, complexity, dependencies and other measurements read from the code are computed for every file in every audit.
• The architecture and the written assessment reuse unchanged work too. The architecture analysis reuses the earlier per-file analysis of every file whose code is unchanged, renamed or changed only in comments or formatting, and analyses the changed and new ones; components, relationships and the architecture summary are rebuilt in every audit. The written assessment of the code is drafted in batches of files: a batch that holds the same files as in the last audit, all unchanged or changed only in comments or formatting, keeps its earlier draft. A batch with a changed, new or renamed file is drafted again, and adding or removing a file can regroup the batches near it, which are then drafted again too.

For every reused file, CodeDD records the audit its result comes from and the date that audit reviewed it.

Comparing audits over time#

The initial audit and every quarterly audit of a company form one history, so the dashboard compares them directly: each quarterly audit holds a complete result for every selected file, either reviewed in that audit or reused.

Light Audits from before the program change stay readable as their own, separate series. They reviewed a sample of files and are not compared with full results.

The monthly pulse#

The monthly pulse refreshes the dependency, delivery and activity figures of a company's latest audit between quarterly audits. It is not a new audit and does not open a navigable report.

The first pulse runs one month after the program's first audit for that company completes, then monthly. Each pulse re-checks the audit's direct dependencies against the versions pinned now and today's advisories, so the CVE figures on the dashboard stay current between audits. Direct dependencies added since the audit are picked up by the next quarterly audit, not by a pulse. When the advisory source cannot be reached, the figures stay those of the audit, and a dependency the pulse could not re-check keeps the audit's figure. An audit the company had before it was enrolled does not start pulses.

A pulse refreshes up to 200 repositories per company within a monthly time budget, active repositories before idle ones. For a company with more, the dashboard says how many were refreshed ("200 of 240 repos"), and the ones left out are refreshed first the next month. Repositories are cloned with only the history the pulse reads (the last five years, or the full history where a merge reaches further back) and are securely deleted as soon as they are read, the same way as for an audit.

What changed from the earlier program#

The earlier program ran a 100-file Light Audit sample each quarter and one included Full Audit per company per contract year. Both are replaced:

• No yearly included Full Audit. The initial audit reviews everything once, and quarterly audits keep every result current, so there is no Full Audit to place at the start or end of the contract year.
• No quarterly sample. A quarterly audit covers every selected file, reviewing the changed ones and reusing the rest, instead of a 100-file sample.
• One-off full audits are still available. You can start a separate full audit from the dashboard at any time. It is its own project and uses your allowance. A one-off full audit does not move the quarterly dates and does not replace a newly enrolled company's initial audit. Only for a company moved from the earlier program does a completed full audit count as its initial audit (see The initial audit).

Existing schedules moved to the new program automatically. A company with a completed full audit continues with quarterly audits. A company with completed Light Audits but no full audit still owes its initial audit, under the same 5 million line cap and confirmation: a fund administrator starts it, as for a new enrollment, and its quarterly audits follow. A company that never completed an audit is treated like a new enrollment.

Enroll a company#

Enrollment is explicit: a company is on the program only after you save a monitoring schedule for it.

1. Open Account → the legal organization's Portfolio Monitoring list, or open the company dashboard and Next Audit.
2. Pick the company if it is not enrolled yet.
3. Name whose Git connection CodeDD should clone with — you, or a member of that company.
4. Save the schedule. Use the start-now option on the form to prepare the first audit today. There is no date to choose: a fund administrator starts the first audit once its repositories are imported and it is marked ready, and the quarterly audits follow from that day.

Only portfolio initiators and enterprise administrators can enroll companies. The plan's PortCo seat allowance caps how many companies can be enrolled at once.

Git connections belong to a person, not a company#

OAuth and personal access tokens live on a CodeDD user account, at most one OAuth connection and one token per Git provider (GitHub, GitLab, Bitbucket, Azure DevOps). They are not stored separately for each portfolio company.

What that means in practice:

• Connecting GitHub, GitLab, or Azure once on Account → Profile → Git provider connections (or during import) is enough for that person to use the same connection on every company they enroll — as long as the same Git user can see that company's repositories.
• A PE or firm CTO who monitors ten companies can hold GitHub and GitLab and Azure on the same CodeDD login. Each provider is a separate connection.
• CodeDD does not keep two GitHub logins, or two GitLab tokens, on one user. Saving a new GitLab token replaces the previous one, whether it was for GitLab.com or a self-managed GitLab server; the same holds for GitHub.com and GitHub Enterprise Server.
• You can point each company's schedule at a different person (a member of that company) so Company A's clone uses their GitLab and Company B uses someone else's GitHub.

GitHub (cloud) uses the CodeDD GitHub App. Access is the repositories selected on each App installation, intersected with what that GitHub user can already see. Installing the App on another GitHub organization adds access; it does not create a second CodeDD GitHub login.

GitLab, Bitbucket, and Azure DevOps grant whatever that connected user can read on that host. There is no separate CodeDD "organization grant" per portfolio company.

Each company has its own repository list#

The Git token is shared. The list of repositories CodeDD clones for monitoring is not.

When you enroll a company you approve the repositories for that company only. The initial audit, quarterly audits and pulses reuse that list. Repositories that were already visible next to the approved ones when the list was set count as left out, and are not flagged.

Repositories that appear after the list was set are never added on their own: they are flagged on the company's schedule and counted in the monitored-companies list, and the company's admins get one email naming them, so the decision can be made before the next scheduled audit. Until someone decides, they are also named in the email that reports each completed audit. On the monitoring form, tick the ones that belong to the company to include them from the next run, or choose Leave out for the ones that do not; either answer clears the flag. The audit runs on the approved list either way. If you had already confirmed the next run's scope when a new repository appears, the confirmation is re-opened and you can confirm again once you have decided.

That is how one person with access to many GitHub organizations or GitLab groups monitors ten companies without mixing their code: pick Company A's repos on Company A's schedule, Company B's on Company B's.

The first-time import dialog asks you to pick a Git host, then an organization / group / workspace, then repositories. Use that when companies live on different hosts, or when you need to add a GitHub organization that does not yet have the CodeDD App.

The schedule's repository checkboxes list what the named Git connection can currently see on the host already linked to that schedule. After the first successful listing, the schedule stays on that host so a GitHub connection cannot silently start cloning an unrelated GitLab estate.

First setup when Git is already connected#

An existing Git connection does not enroll a new company by itself.

Typical path for the first audit on a brand-new schedule:

1. CodeDD opens Audit Invitation for the initial audit (nothing has been approved to clone yet).
2. Import repositories. If that host is already connected, you skip the authorize popup and go to organization / group, then repository selection.
3. Check the file selection and mark the audit ready.
4. A fund administrator presses Start. CodeDD then starts the audit, or first asks them to agree to the lines above 5 million. Those imported repositories become the approved list for every later unattended run, and the file selection is the one quarterly audits continue from.

You can instead save the schedule and tick repositories on the monitoring form. The initial audit still waits for a person to import the repositories into it and mark it ready, and for a fund administrator's Start — a per-company selection, not a second OAuth grant.

Reconnect access on the schedule card is only when the weekly health check finds the named connection missing or failing. It is not required every time you add a company.

After the first run#

Quarterly audits and monthly pulses clone the approved repositories with the named person's connection. You are not asked to authorize Git or accept repositories again unless:

• the connection breaks (token expired, App uninstalled, person left) — reconnect or pick someone else;
• CodeDD finds new repositories next to the approved ones — they are flagged and emailed, not added; tick them to include them or leave them out;
• the next run's repository list drifted and you are asked to confirm the scope the day before.

Between audits CodeDD keeps, for each file, its path and the Git identifier of the version the AI reviewed, so the next audit can tell what changed. The clone itself is not kept: it is securely deleted after the audit, as for any other audit.

Funds with many portfolio companies#

A typical private-equity CTO with ten companies:

• Connects GitHub, GitLab, and Azure DevOps once on their CodeDD account.
• Installs the CodeDD GitHub App on each GitHub organization that needs monitoring, selecting the repositories GitHub should expose to CodeDD.
• Enrolls each company and selects that company's repositories (invitation import or schedule checkboxes).
• Sets each company's initial audit going by hand (the Repo Owner imports the repositories, checks the file selection and marks the audit ready; a fund administrator presses Start), then leaves the quarterly audits and pulses to run on their own, reviewing any new repositories CodeDD flags.

They do not get a separate OAuth grant stored per company. Isolation is the per-company repository list, plus GitHub App installations on the GitHub side. If two companies must never share a Git identity, assign different CodeDD users as each schedule's Git connection, or use a dedicated Git service account per company.

Troubleshooting#

Frequently asked questions#

Short answers to the questions people ask most about Portfolio Monitoring audits. Each answer names the section that explains the topic in full.

Does a quarterly audit review every file again?#

No. A quarterly audit re-reviews only the files whose code changed since the AI last reviewed them, plus new files the import selects. Every other selected file keeps its last result. See Quarterly audits.

Does a comment or formatting change trigger a new review?#

No. Edits to comments, docstrings or formatting alone keep the earlier result. Indentation counts as a change in indentation-sensitive languages such as Python and YAML. See What counts as a change.

How old can a reused result be?#

There is no age limit. A file that has not changed keeps the result of the audit that last reviewed it, and CodeDD records that audit and its date. See Reused results and security findings.

Does a finding I dismissed come back in a quarterly audit?#

No, not while a later audit reuses the file's result, which it does while the file's code stays the same. Findings you marked as not an issue, resolved or commented on keep that triage in every audit that reuses the result, and the AI does not validate them again. If the file is reviewed again, because its code changed or because CodeDD could not reuse the earlier result in that audit, its findings start without triage. See Reused results and security findings.

Are files added later to a folder I deselected reviewed?#

Only if you did not keep them out. When you save a folder deselection on the scope screen of the initial audit, the Files added later dialog offers a rule that keeps new files in that folder out of later audits, ticked by default. With that rule, a new file there is not reviewed. Without it, a new file the import selects is reviewed, also in a folder you deselected. The files that were already in the folder stay deselected either way. A folder you deselected before rules existed has no rule yet, and you can add one between audits in Portfolio Admin under Code & Repositories. See Scope rules.

How do I keep a file type out of later audits?#

Add an exclude rule for the file type, for example .sql, for one repository or for every repository of the company. On the scope screen of the initial audit, deselect the file type with its File Extensions chip, save, and keep the offered rule ticked. Later, between audits, add it in Portfolio Admin under Code & Repositories, from a repository's rules or from Company rules. The rule decides files added from then on. The files of that type already in scope keep the selection they have. See Scope rules.

Why is an include line in the Files added later dialog not ticked?#

A rule that includes files also brings in new tests, vendored and generated files that match, which the import leaves out. A file type chip, for example, selects every file of that type, also under vendor/ and in test folders. The dialog therefore leaves a line that includes files unticked, and you tick it when you want that. A line that excludes files starts ticked, because it only narrows the audit. With every line unticked, Save stores the file selection and no rule. See Scope rules.

Can I see the saved rules before the initial audit starts?#

Yes. Before a fund administrator presses Start, Portfolio Admin shows the saved rules read-only under Code & Repositories: a note says how many apply to later audits, and View rules opens the list by repository. Rules are added and removed on the scope screen of the initial audit. Nobody changes them from that list. See Scope rules.

Can I add a folder back after the initial audit?#

Yes. In Portfolio Admin, open the company, then Code & Repositories, and use Edit later scope on the repository, or use Scope for later audits on the company's dashboard. Tick the folder, review the summary and submit. The change starts with the next quarterly audit that has not yet worked out what changed for the repository. Files in the folder that no audit ever reviewed are reviewed as new and count against the included lines first, then the annual allowance, which a fund administrator agrees to. Files reviewed before are reused if their code has not changed. Files in the folder marked "Kept out by your scope rules", typically ones below your minimum lines, stay out unless you tick them one by one. Files an exclude rule kept out in an earlier audit come back with the folder. You can withdraw the change until an audit has picked it up. See Changing the scope for later quarters.

Who can change what quarterly audits cover?#

Fund administrators and the company's portfolio initiators, with Scope for later audits in Portfolio Admin or on the company's dashboard. The Repo Owner and the company's team cannot, and the scope screen of a quarterly audit is read-only for everyone. The exception is the first quarterly audit of a repository added later, whose file selection the people involved with the company can change until it starts (see Which files a quarterly audit covers). Only a fund administrator agrees to use the annual allowance. See Changing the scope for later quarters.

Do quarterly audits use my lines of code allowance?#

No. Quarterly audits use no lines, including the lines they re-review, and neither does a repository reviewed in full for the first time. Only the initial audit draws on the allowance, above its included 5 million lines. The one exception is Scope for later audits: files you bring back that no audit ever reviewed count against the included lines first, then the allowance. See The initial audit and Lines of code for files you bring back.

Is there still an included yearly Full Audit?#

No. The initial audit reviews every file once, and quarterly audits keep every result current. A separate one-off full audit can still be started from the dashboard. See What changed from the earlier program.

Can I compare the initial audit with later quarterly audits?#

Yes. The initial audit and the quarterly audits form one history on the dashboard. Light Audits from before the change stay a separate series. See Comparing audits over time.

Next steps#

• CVE Alerts
• Setting Up a Portfolio Organization
• Repository Connection & Security
• Team Members & Access Roles
• Enterprise Data API