Fact · documented
Auth Service
Owner: Identity Platform
Confidence: High. Stated in a source document.
Private technical alpha · Advisory and supervised
THUS MaxKnow what a change could affect—before you make it.
Max helps engineering teams identify affected systems, relevant owners, evidence, unknowns, and the checks needed to verify a change.
Start with a short description. We’ll agree on the scope and evidence needed before you share internal material.
What a Max answer looks like
One proposed change, with facts, inferences, and unknowns kept distinct—so a reviewer can see what to trust and what to check.
Illustrative example
Session policy review
Proposed change
Extend session lifetime
24 hours→7 days
Affected systems, owners and evidence
Fact · documented
Partner API
Owner: Partner Engineering
Confidence: High. Stated in a source document.
Inference · not confirmed
Payments
Owner: unconfirmed. Release history suggests it may be affected. This is not a confirmed dependency.
Confidence: Medium. Needs an owner to confirm.
Unknown · no evidence found
External partner caching
External partner caching behavior has not been verified. Ask the partner owners whether sessions or tokens are cached.
Required before release
- Security review
- Token revocation tests
- Token expiry tests
Open questions for humans
- Who owns Payments for this path?
- Do external partners cache sessions?
Max recommendation
Hold until the security review and required evidence are in.
A person makes the call. Max supplies the reasoning and marks what is still open.
Verification criteria
- Revoked tokens are denied.
- Expiry behaves as intended for both clients.
For teams whose changes cross boundaries.
Max is being built for software engineers, data teams, technical leads, and incident responders who need to reason across more than one repository or tool. A small diff can affect a downstream report, a service owned by another team, or a promise the business has made.
Start with one consequential workflow: reviewing a shared interface, changing a data pipeline, or investigating a failure that spans systems. Bring a past example so the team can assess the dependencies Max surfaces and the questions it asks.
Recurring work, not one-off prompts.
Choose a change or incident your team knows well. Each workflow starts with a real decision and an agreed set of evidence.
- 01
Review a service or schema change
What else depends on the behavior we are about to change?
A team proposes changing an API field, database schema, or retry policy. Relevant evidence may include consumers, ownership, previous failures, tests, and release constraints. An advisory assessment should distinguish confirmed dependencies from possible impact and identify what still needs a human check.
Evaluate against the engineer’s review: did Max identify a meaningful dependency, cite its basis, and ask a useful question before implementation?
- 02
Investigate a data pipeline change
Could a locally correct change make a business result wrong?
A transformation, event definition, or scheduling change can alter a dashboard or downstream decision even when its tests pass. The investigation should trace the relevant data path, clarify who uses the output, and make the assumptions about freshness and meaning explicit.
Evaluate against a known workflow: can the explanation connect a technical change to the affected output without treating an unverified dependency as fact?
- 03
Reconstruct an incident
Which expectation stopped being true, and what evidence supports that?
After a release or an unexpected failure, compare intended behavior with the available timeline, changes, and observations. Separate symptoms from candidate causes; mark missing signals and conflicting accounts. A responder should be able to inspect the reasoning rather than accept a confident summary.
Evaluate against a past incident: does the investigation connect the timeline to the relevant changes, identify conflicting evidence, and make the next question clear?
Company-aware means context with a reason.
The same code change can carry different consequences in different companies. A dependency matters because of what it supports, who owns it, the constraints on changing it, and what previous work has taught the team.
- 01
Connect technical and organizational context
Company-aware reasoning connects an affected component to its owners, business use, previous decisions, and constraints—not merely to another file. THUS Core is the company knowledge foundation being built to support that context.
- 02
Keep facts, inferences, and unknowns separate
A documented consumer is evidence. A likely downstream effect is an inference. An unconfirmed owner or missing test is an unknown. Useful advice states which is which and explains what would confirm or disprove the conclusion.
- 03
Make corrections part of the work
An expert may know that a dependency has changed or that an apparent risk is irrelevant. Review the reasoning with that expert, correct the evidence, and make the basis for the decision explicit.
A longer lifecycle than a coding task.
The alpha starts with consequence prediction and investigation. The broader product direction is to keep company context with the work before, during, and after implementation, alongside the coding agents your team already uses.
- 01
Before implementation
Alpha focus
Identify the intent, affected systems, owners, constraints, and unknowns. Inspect the evidence before deciding how to proceed.
- 02
During the work
Product direction
Companion is being developed to supply company context to the engineer and coding agent, then compare the actual diff with the agreed intent and scope.
- 03
When reality diverges
Product direction
Assurance Cases and Action Envelopes would keep expectations, boundaries, signals, and approvals explicit, helping a human responder investigate and recommend a bounded recovery.
- 04
After the outcome
Product direction
The intended lifecycle checks what actually happened and preserves expert corrections and lessons for the next decision.
Start with one past change or incident.
Choose something your team can explain and evaluate. We’ll use that example to agree on a narrow question, inspect the reasoning together, and decide whether Max is useful for your workflow.
- 01
Choose the question
Agree on one recurring change or investigation and what a useful answer would contain. Identify the engineer or domain expert who can judge the result.
- 02
Review alongside existing work
Inspect the assessment alongside your team’s original review or incident investigation. Check which dependencies, owners, constraints, and unknowns help answer the question.
- 03
Compare with expert judgment
Inspect cited evidence, missed dependencies, unsupported inferences, and useful unknowns. Record corrections and decide together whether the workflow warrants further evaluation.
Start with a short description. We’ll agree on the scope and evidence needed before you share internal material.
Alpha boundaries
The private technical alpha focuses on consequence prediction and investigation for engineering and data teams.
- Your team stays in control
- Evaluations begin read-only and in shadow mode. Max is advisory and supervised; your existing reviews, approvals, and incident ownership remain the authority. Max does not take production control.
- The longer lifecycle is the direction
- Companion, Assurance Cases, Action Envelopes, live on-call assistance, recovery verification, and durable outcome learning are in development or product vision, rather than released end-to-end capabilities.
- Scope is agreed before access
- We agree on access, data scope, handling expectations, and connection points before an evaluation. Potential integrations are not a list of live connections. THUS does not currently claim security certifications.
- Evidence decides what comes next
- The output example uses fictional systems, owners, and source references; it is not a customer result. We assess usefulness against your team’s judgment rather than promise performance improvements.
THUS AI is building AI teammates and agents for companies that learn and grow with the business, predict how changes affect people and systems, and stay with the work through execution, incidents, and verified outcomes. Max is the first teammate in that company-wide ambition.
THUS is also known online as withthus.